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ABSTRACT 

As  demand  lor  hard  real-time  and  embedded  computer  systems  increases,  a  new 
approach  to  software  development  is  critical.  Software  engineers  and  users  would  ben¬ 
efit  from  an  automated  methodology  allowing  validation  of  design  specifications  or 
functional  requirements  early  in  the  development  life  cycle.  A  fast,  cilicient,  easy-to-use 
tool  would  increase  productivity  and  would  enhance  user  confidence  tiiat  software  would 
be  delivered  at  less  cost  and  on  schedule.  The  Computer  Aided  Prototyping  System 
(CAPS)  is  a  conceptualized  tool  providing  these  capabilities. 

This  thesis  represents  a  pioneering  effort  to  develop  a  Static  Scheduler  for  the  CAPS 
Execution  Support  System  using  the  Ada'5*  programming  language.  The  Static  Scheduler 
initially  extracts  critical  operators,  timing  constraints  and  precedence  relationships  from 
a  high-level  prototype  source  program.  The  Static  Scheduler  then  creates  a  static 
schedule  for  run-time  execution,  using  worst  case  scenarios,  guaranteeing  that  timing 
constraints  are  met.  The  primary  goal  of  this  thesis  is  to  provide  the  scheduling  algo¬ 
rithms  and  implementation  guidelines  for  the  Static  Scheduler.  Secondary'  goals  arc  to 
demonstrate  the  significance  of  continued  research  to  telecommunications  applications 
and  .0  demonstrate  the  feasibility  of  Ada®  as  the  implementation  language.  (Ada®  is  a 
registered  trademark  of  the  United  States  Government,  Ada  Joint  Program  Ollice.) 
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I.  INTRODUCTION 


BACKGROUND 


The  Department  of  Defense  (DOD)  and  the  Department  of  the  Navy  (DON)  allo¬ 
cate  billions  of  dollars  each  year  for  initial  development  or  maintenance  of  progressively 
more  complex  weapons  and  communications  systems.  These  advanced  systems  in¬ 
creasingly  rely  on  requirements  for  hard  real-time  processing  of  information,  utilizing 
embedded  computer  systems  to  monitor  or  control  system  performance.  These  embed¬ 
ded  systems  currently  perform  time-critical  functions  that  are  primarily  computational 
in  nature,  such  as  missile  guidance  or  communications  network  control.  As  early  as 
1973,  studies  showed  that  computer  software  alone  comprised  approximately  46  percent 
(over  3  billion  dollars)  of  the  estimated  total  DOD  computer  costs  of  7.5  billion  dollars. 
In  addition,  56  percent  of  these  software  costs  were  devoted  specifically  to  embedded 
systems.  [Ref.  1:  p.  14] 

As  they  approach  the  21st  century,  the  DOD  and  the  DON  will  be  faced  with  ever 
increasing  demands  for  complex,  hard  real-time  or  embedded  systems.  This  growth  of 
and  dependency  on  embedded  systems  is  readily  apparent  when  compared  with  the 
growing  civilian  reliance  on  similar,  small-scale  systems  to  prepare  their  food  and  "drive" 
their  automobiles.  Considering  the  growth  of  software  development  and  maintenance 
costs  versus  computer  hardware  costs,  users  must  insist  that  systems  are  received  on 
schedule  and  are  responsive  to  stated  needs;  that  they  are  reliable,  efficient  and  within 
cost  estimates;  and,  that  they  are  modifiable  and  transportable  to  other  applications. 
Fulfilling  these  user  demands  requires  a  systematic  approach  to  software  development 
and  an  ability  to  deal  with  complex  solutions. 

1.  Software  Engineering 

Software  engineering  is  the  application  of  science  and  mathematics  (specifically 
algorithms)  by  which  the  capabilities  of  computers  are  made  useful  through  the  appli¬ 
cation  of  computer  software  programs,  procedures  and  related  documentation.  Gener¬ 
ally  accepted  goals  for  software  engineering  fall  under  the  two  related  categories  of 
performance  and  design  quality.  System  performance  is  of  primary  importance  to  the 
user.  A  delivered  software  system  must  accurately  represent  the  user's  stated  require¬ 
ments  and  also  consistently  produce  highly  reliable  responses  within  the  anticipated  en¬ 
vironment.  Quality  of  the  design  is  becoming  increasingly  important  to  both  the  user 
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and  the  systems  engineer.  A  delivered  system  must  be  efficient  in  its  use  of  resouiccs, 
understandable,  and  modifiable  in  order  to  minimise  modification  or  maintenance  costs 
in  the  future.  These  goals  are  achievable  by  utilizing  a  modular  architecture,  localization 
of  logically-related  resources,  uniformity  of  notation,  accuracy  of  the  minimum  required 
elements  and  confirmability  through  the  use  of  demonstrations.  [Ref.  1:  pp.  29-35] 
Software  engineering  encourages  the  use  of  a  development  life  cycle  methodology  that 
systematically  and  consistently  incorporates  these  goals  and  principles  in  the  creation 
of  software  systems. 

2.  Traditional  Life  Cycle 

The  traditional  waterfall  life  cycle  methodology  currently  used  for  developing 
large  software  programs  incorporates  individual  development  stages.  These  stages  in- 
c’”de  requirements  analysis,  functional  specifications,  architectural  design,  module  de¬ 
sign,  implementation  and  testing.  Requirements  analysis  establishes  the  purpose  of  the 
intended  system  and  defines  the  currently  perceived  constraints  or  boundaries  within 
which  the  system  will  function.  The  functional  specifications  define  aspects  and  inter¬ 
faces  of  the  proposed  system  that  are  visible  to  the  user.  The  architectural  design  de¬ 
scribes  a  high-level  model  of  the  system  while  module  design  describes  the  algorithms 
and  data  structures  for  implementing  the  architectural  design.  The  implementation  stage 
involves  the  actual  hand  coding  of  the  executable  programs  in  a  programming  language 
which  are  then  tested  for  performance  accuracy.  These  stages  are  normally  completed 
individually  and  sequentially  before  system  performance  is  validated  by  the  user.  In¬ 
consistencies  with  expected  performance  could  result  in  minor  changes  to  software  im¬ 
plementation  or  in  drastic  modifications  if  design  misconceptions  occurred  during  the 
requirements  analysis  or  functional  specification  stages.  Depending  on  the  full  impact 
of  these  inconsistencies,  delivery  dates  could  slip,  costs  in  dollars  and  man-hours  could 
increase,  and  the  overall  reliability  and  accuracy  of  the  software  product  could  be  in 
question. 

When  this  traditional  life  cycle  approach  is  applied  to  hard  real-time  or  embed¬ 
ded  systems,  the  potential  for  major  inconsistencies  increases.  One  of  the  major  differ¬ 
ences  between  a  real-time  system  and  a  conventional  computer  system  is  the  requited 
precision  and  accuracy  of  the  application  software.  'I  he  response  time  of  each  individual 
operation  may  have  a  unique  value  to  the  system  which  varies  with  time  In  hard  real¬ 
time  systems  this  response  time  is  a  critical  Octet  mining  factor  in  the  accuracy  of  the 
software.  These  response  times,  or  deadlines,  must  be  met  or  the  system  will  fail  to 


function  correctly,  often  leading  to  catastrophic  consequences.  [Kef.  2:  p.  113]  I  or 
example,  as  part  of  a  larger  computer  system,  an  embedded  system  can  incorporate 
stringent  real-time  constraints,  parallel  processing  using  two  or  more  computers,  and  a 
high  degree  of  reliability.  These  requirements  will  often  exceed  the  capacity  or  capabil¬ 
ities  of  one  software  engineer,  but  may  instead  require  several  individuals  working  inde¬ 
pendently  on  different  segments  of  the  system.  In  summation,  without  the  aid  of 
automated  software  tools,  development  of  hard  real-time  systems  using  a  traditional  life 
cycle  approach  can  become  inefficient  and  less  effective. 

3.  Rapid  Prototyping 

a.  Conventional  Rapid  Prototyping 

Current  research  suggests  a  revised  methodology  for  the  software  devel¬ 
opment  life  cycle,  especially  when  designing  hard  real-time  systems,  which  consists  of 
two  phases,  rapid  prototyping  and  automatic  program  generation  (Ref.  3:  p.  2|.  Al¬ 
though  current  capabilities  preclude  completely  automatic  program  generation,  the  re¬ 
quired  software  tools  and  capabilities  do  exist  for  rapid  prototyping.  As  a  software 
methodology,  rapid  prototyping  provides  the  user  and  designer  with  a  fast,  efficient  and 
easy-to-use  stepwise  process.  When  utilized  during  the  early  stages  of  the  development 
life  cycle,  rapid  prototyping  allows  validation  of  the  requirements,  specifications  and  in¬ 
itial  design  before  valuable  time  and  effort  are  expended  on  implementation  software. 

Figure  1  on  page  4  graphically  describes  this  methodology  as  a  typical 
feedback  loop  [Ref.  4:  p.  3].  Rapid  prototyping  initially  establishes  an  iterative  process 
between  the  user  and  the  designer  to  concurrently  define  specifications  and  requirements 
for  the  time  critical  aspects  of  the  envisioned  system.  The  designer  then  constructs  a 
model  or  prototype  of  the  system  in  a  high-level,  prototype  description  language.  This 
prototype  is  a  partial  representation  of  the  system,  including  only  those  critical  attributes 
necessary  for  meeting  user  requirements,  and  is  used  as  an  aid  in  analysis  and  design 
rather  than  as  production  software.  [Ref.  4:  pp.  2-5]  During  demonstrations  of  the 
prototype,  the  user  validates  the  prototype's  actual  performance  against  its  expected 
performance.  If  the  prototype  fails  to  execute  properly  or  to  meet  any  critical  timing 
constraints,  the  user  identifies  required  modifications  and  redefines  the  critical  specifi¬ 
cations  and  requirements.  This  process  continues  until  the  user  determines  that  the 
prototype  successfully  meets  the  time  critical  aspects  of  the  envisioned  system.  Follow¬ 
ing  this  final  validation,  the  designer  uses  the  validated  requirements  as  a  basis  for  the 
design  and  eventual  hand  coding  of  the  production  software. 


Figure  1.  Rapid  Prototyping  Method 

b.  Computer-Aided  Rapid  Prototyping 

Computer-aided  rapid  prototyping  further  refines  the  efficiency  and  accu¬ 
racy  of  this  new  methodology.  While  utilizing  the  same  iterative  approach,  computer- 
aided  rapid  prototyping  relies  on  three  major  software  tools  which  assist  the  designer  in 
constructing  and  executing  the  prototype.  First,  the  computer-aided  environment 
includes  a  software  base  management  system  which  creates  uniform  retrieval  specifica¬ 
tions  for  software  modules  in  the  software  database  and  later  retrieves  these  reusable 
modules  for  assembling  the  executable  prototype.  Second,  a  graphics-capable  user 
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interface  including  a  syntax-directed  editor  expedites  the  designer's  data  entry  at  a  ter¬ 
minal  and  prevents  syntax  errors  in  the  design.  Finally,  an  execution  support  sjeem 
demonstrates  and  measures  the  prototype's  performance  and  analyzes  the  accuracy  of 
design  specifications.  [Ref.  5:  p.  4]  Chapter  11  of  this  thesis  describes  the  first  two 
tools  in  more  detail  while  Chapter  III  provides  a  detailed  description  of  the  third  tool. 

A  computer-aided  rapid  prototyping  approach  will  provide  the  software 
designer  with  a  powerful  tool,  designed  specifically  for  development  of  hard  real-time  or 
embedded  systems.  Although  the  traditional  approach  may  also  produce  an  acceptable 
product,  rapid  prototyping  suggests  significant  advantages  in  several  major  areas.  De¬ 
signing  a  simplified  executable  prototype  of  the  envisioned  system  forces  the  user  and 
the  designer  to  decompose  a  complex  system  into  its  major  components.  This  process 
creates  modules  that  individuals  can  easily  understand  and  manage.  This  modularized 
design  is  enforced  by  a  formal  prototyping  language  based  on  abstractions  of  the  sys¬ 
tem's  requirements  and  high-level  constructs  of  the  language  itself.  A  computer-aided 
rapid  prototyping  approach  using  a  modularized  design  focuses  the  designer's  attention 
on  analysis  of  the  requirements  and  specifications  of  the  system.  At  this  stage,  the  de¬ 
signer  should  concern  himself  with  the  architectural  decomposition  of  a  complex  system 
rather  than  becoming  engrossed  with  detailed  programming  efforts  inherent  in  conven¬ 
tional  prototyping.  This  approach  allows  the  user  to  verify  requirements  and  to  idetrifv 
problem  areas  early  in  the  development  cycle.  This  verification  process  eliminates  ex¬ 
pensive  redesign  efforts  and  increases  the  user's  confidence  that  the  system,  as  envi¬ 
sioned,  is  feasible.  [Ref.  3:  pp.  2-3J 

Rapid  prototyping  oilers  promising  advantages  in  improved  software  engi¬ 
neering  productivity,  increased  reliability  of  the  finished  product,  more  realistic  cost  es¬ 
timates  based  on  identified  system  complexity,  and  a  reduction  in  the  total  conception 
to  operational  timeframe  [Ref.  4:  pp.  11-12].  Ongoing  research  and  pioneering  dibits 
must  now  fully  elevate  computer-aided  rapid  prototyping  from  its  conceptualized  design 
into  a  functioning  reality. 

B.  OBJECTIVES 

f  ins  thesis  describes  the  design  and  implementation  elforts  for  the  Static  Scheduler 
subsystem  of  the  Execution  Support  System  (ESS)  for  the  Computer  Aided  Prototyping 
System  (CAPS).  The  primary  objective  of  this  thesis  is  to  present  the  algorithms  which 
successfully  schedule  the  critical  time  constraints  in  a  hard  real-time  or  embedded  system 
model  and  to  establish  implementation  guidelines  for  the  Static  Scheduler.  In  achieving 


this  objective,  this  thesis  will  also  document  the  Ada’5'  programming  language  con¬ 
structs  utilized  in  developing  the  Static  Scheduler. 

C.  ORGANIZATION 

Chapter  II  describes  the  external  rapid  prototyping  environment  where  a  Static  Sched¬ 
uler  is  utilized  to  execute  the  prototype  of  a  hard  real-time  system.  This  environment 
includes  the  CAPS  and  the  Prototype  System  Description  Language  (PSDL).  This 
Chapter  also  presents  the  software  tools  used  in  developing  the  Static  Scheduler. 
Chapter  III  concentrates  on  the  CAPS  Execution  Support  System  and,  specifically,  its 
Static  Scheduler.  The  interfaces  between  and  responsibilities  of  the  Dynamic  Scheduler, 
Translator  and  Static  Scheduler  subsystems  arc  outlined,  stressing  the  importance  of  the 
Static  Scheduler  in  ensuring  accurate  execution  of  critical  timing  constraints.  Chapter 
IV  outlines  the  analyse'  «nd  programming  decisions  that  were  made  or  encountered 
during  development  of  these  guidelines.  Chapter  V  presents  an  application  of 
computer-aided  rapid  prototyping  to  a  telecommunications  switching  system.  Chapter 
VI  presents  conclusions  and  recommendations  stemming  from  this  pioneering  research 
effort. 


1  Add®  is  a  registered  trademark  of  the  United  Slates  Government,  Ada  Joint  Program  Office. 


II.  EXTERNAL  ENVIRONMENT 


A.  ELEMENTS  OF  THE  EXTERNAL  ENVIRONMENT 

Computer-aided  rapid  prototyping  and  its  revised  outlook,  on  the  development  life 
cycle  is  a  familiar  topic  with  software  engineering  and  development  professionals.  But 
to  the  new  entrant  or  to  procurement  liaison  personnel,  a  basic  appreciation  for  the 
complexity  of  creating  prototypes  for  hard  real-time  systems  would  prove  beneficial. 
This  Chapter,  therefore,  covers  the  major  areas  which  affect  or  help  create  the  environ¬ 
ment  within  which  the  Static  Scheduler  operates.  First,  a  description  of  the  CAPS  and 
PSDL  provides  the  reader  with  a  greater  understanding  of  the  contribution  that  the 
Static  Scheduler  makes  to  prototype  development.  The  Chapter  concludes  with  a  de¬ 
scription  of  the  Kodiyak  translator  generator,  the  Ada®  programming  language,  and  the 
hard  real-time  system  model  that  were  used  in  implementing  the  Static  Scheduler. 

B.  COMPUTER  AIDED  PROTOTYPING  SYSTEM  (CAPS) 

The  computer-aided  rapid  prototyping  tool  addressed  in  this  thesis  which  incorpo¬ 
rates  a  Static  Scheduler  is  the  CAPS.  Pveeognizing  that  available  prototyping  method¬ 
ologies  require  extensive  amounts  of  individual  time  and  effort,  CAPS  is  designed 
specifically  as  a  development  tool  for  hard  real-time  systems.  Its  primary  objective  is 
development  of  a  specification  method  for  identifying  and  later  retrieving  reusable  soft¬ 
ware  components  from  an  online  database  while  utilizing  a  formal  prototyping  language. 
Together  with  an  iterative  process  similar  in  concept  to  Figure  1  on  page  4,  CAPS  will 
provide  an  effective  and  efficient  tool  for  constructing  and  validating  a  prototype. 
[Ref.  4:  pp.  1-2]  Rapid  construction  of  this  prototype  relies  on  the  applicable  proto¬ 
typing  method  and  on  a  support  environment  which  automates  the  steps  involved.  The 
following  sections  and  Figure  2  on  page  S  describe  the  components  of  the  CAPS  archi¬ 
tecture  and  how  they  work  together  to  make  computer-aided  rapid  prototyping  possible. 

1.  Components  of  CAPS 

CAPS  is  initialized  through  the  User  Interface  (LI)  as  the  user  and  designer 
work  together  in  defining  the  critical  attributes  of  the  envisioned  system.  The  LI  con¬ 
sists  of  a  syntax-directed  editor  for  the  formal  prototyping  language  and  a  graphics  tool 
for  displaying  data  (low  diagrams.  The  editor  eliminates  syntax  errors  by  prompting  the 
designers  with  appropriate  alternatives  at  each  step  of  the  design  process.  The  graphics 
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Figure  2.  CAPS  Architecture 


tool  provides  a  picture  of  the  data  flow  diagrams  which  reinforces  the  verbal  description 
of  the  system  specifications.  [Ref.  6:  pp.  6-7] 

The  Prototype  System  Description  Language  (PSDL)  was  designed  as  the  pri¬ 
mary  connection  between  the  designer  and  the  remaining  components  of  CAPS.  By 
definition,  PSDL  is  a  high-level  prototyping  language  with  special  features  appropriate 
for  defining  critical  real-time  constraints  and  is  applied  at  the  specification  or  design 
stage.  [Ref.  7:  pp.  3,  23 j  In  order  to  rapidly  construct  a  prototype,  PSDL  also  in¬ 
cludes  its  own  associated  prototyping  method  and  automated  support  environment. 
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L'sing  a  top-down  design  approach,  the  l’SDL  method  aids  tire  designer  in  systematically 
refining  and  decomposing  each  critical  component  into  its  lower  level  components. 
Uniform  PSDL  specifications  associated  with  each  lower  level  description  act  as  tem¬ 
plates  for  retrieving  reusable  software  components  having  similar  specifications  Crotn  the 
CAPS  Software  Database.  Thus,  the  PSDL  method  produces  a  computational  model 
consisting  of  the  basic  building  blocks  needed  to  describe  the  abstractions  and  concepts 
of  the  hierarchically  structured  prototype.  The  PSDL  execution  support  environment 
then  verifies  the  design  and  the  validity  of  the  prototype's  real-time  requirements.  The 
actual  execution  of  the  prototype  demonstrates  whether  these  critical  timing  constraints 
will  perform  in  an  acceptable  manner  that  meets  the  timing  constraints  of  the  system  as 
a  whole  [Ref.  6:  pp.  2-7].  A  detailed  description  of  PSDL  appears  later  in  this  chapter. 

The  CAPS  Rewrite  Subsystem  provides  a  means  for  automatically  generating 
uniform  specifications  for  each  reusable  software  module  in  the  CAPS  Software  Data¬ 
base  and  for  each  PSDL  lower  level  component.  Existing  methods  for  retrieving  reus¬ 
able  modules  are  based  on  keywords.  The  Rewrite  Subsystem,  however,  uses  an 
approach  which  allows  the  designer  to  give  more  precise  PSDL  specifications.  The  Re¬ 
write  Subsystem  then  transforms  each  specification  into  a  uniform  or  normal  form.  This 
transformation  is  achieved  by  mapping  a  semantic  alias  to  its  normalized  term  as  shown 
in  Figure  3  on  page  10.  [Ref.  3:  pp.  7-S]  These  normalized  specifications  are  free  from 
ambiguity  and  create  a  template  used  by  the  Software  Design  Management  System 
(SDMS)  to  retrieve  soltwaie  modules  from  the  database  with  corresponding  normalized 
specifications  [Ref.  8:  pp.  3-1 OJ. 

The  SDMS  is  similar  to  a  database  management  system  with  additional  features 
required  for  computer-aided  design  applications.  The  SDMS  is  responsible  for  organiz¬ 
ing.  retrieving  and  instantiating  the  reusable  software  modules  from  the  CAPS  Database. 
Retrieval  of  reusable  modules  is  supported  by  the  normalized  specification  templates 
described  above.  The  SDMS  instantiates  these  modules  as  specified  by  the  designer  for 
execution  of  the  current  PSDL  prototype.  Overall,  the  SDMS  supports  efficient  se¬ 
lection  and  retrieval  of  the  relevant  software  modules.  [Ref.  3:  p.  9]  This  minimizes 
instances  where  a  non-match  requires  manual  creation  of  a  new  software  module  before 
execution  of  the  prototype  occurs. 

Two  distinct  subdivisions  of  the  CAPS  Database  are  the  Prototype  Database 
and  the  Software  Database.  The  first  maintains  and  manages  the  PSDL  prototypes 
along  with  their  sets  of  requirements.  It  also  records  successive  refinements  of  the 
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READ  GET,  FETCH.  OBTAIN,  INPUT,  RETRIEVE 
UPDATE  CHANGE,  MODIFY,  REFRESH,  REPLACE 

Replace  all  occurences  of  an  alias  with  its  term. 

Example:  "RETRIEVE  temperature  from  thermometer  and 
REFRESH  the  temperature_reading" 

is  normalized  to 

"READ  temperature  from  thermometer  and 
UPDATE  temperaturejreading" 


Figure  3.  Normalizing  a  Specification 

prototype  alternatives.  This  process  includes  facilities  for  backtracking  to  previous 
versions  or  for  combining  successive  design  decisions  from  the  different  alternatives. 
[Ref.  5:  p.  10)  The  Software  Database  contains  the  reusable  software  modules  together 
with  their  PSDL  normalized  specifications.  This  database  allows  future  growth  as  new 
modules  are  identified  for  inclusion  into  the  database. 

The  ESS,  although  a  component  of  the  CAPS  architecture,  actually  provides  the 
execution  support  environment  for  the  PSDL  prototyping  method.  After  assembling  a 
prototype  of  the  envisioned  system,  the  three  ESS  subsystems  provide  the  capability  to 
demonstrate  the  prototype's  actual  performance.  One  subsystem,  the  Static  Scheduler, 
reads  the  PSDL  prototype  source  program  to  identify  and  extract  tire  PSDL  operators 
with  their  timing  constraints  and  precedence  relationships.  For  operators  with  critical 
timing  constraints,  the  Static  Scheduler  creates  a  static  schedule,  if  a  feasible  one  exists, 
guaranteeing  their  accurate  execution  using  worst  case  time  scenarios.  A  second  sub¬ 
system,  the  Translator,  also  reads  and  translates  the  PSDL  prototype  source  program 


co  augment  implementation  of  atomic  operators  and  data  types  with  software  code.  The 
Translator  accomplishes  this  by  communicating  the  PSDL  prototype's  specifications  to 
the  SDMS  and  assembling  the  executable  prototype  from  the  reusable  software  modules. 
The  final  subsystem,  the  Dynamic  Scheduler,  maintains  run-time  execution  control  of 
the  prototype  using  the  completed  static  schedule.  The  Dynamic  Scheduler  must  also 
schedule  operators  without  critical  timing  constraints  during  any  excess  time  slots  that 
remain  after  each  time  critical  operator  completes  execution.  (Ref.  4;  pp.  6-7]  These 
subsystems,  and  specifically  the  Static  Scheduler,  are  described  in  detail  in  Chapter  III 
of  this  thesis. 

2.  Prototype  Development  with  CAPS 

Development  of  an  executable  prototype  with  CAPS  requires  an  improved 
modular  design  which  supports  retrieval  of  reusable  software  modules  and  an  automated 
support  environment  which  minimizes  the  designer's  manual  involvement  in  searching 
for  and  retrieving  the  appropriate  software  modules.  The  individual  CAPS  subsystems 
that  provide  these  automated  capabilities  are  shown  in  Figure  2  on  page  8  and  are  de¬ 
scribed  in  the  previous  section.  Figure  4  on  page  12  illustrates  the  process  that  the  de¬ 
signer  uses  to  interact  with  the  CAPS  to  develop  a  prototype. 

Initially,  the  user  and  the  designer  jointly  determine  the  specifications  of  the 
envisioned  software  system.  The  Rewrite  System  then  normalizes  these  specifications  in 
order  to  formulate  the  database  queries.  The  SDMS  utilizes  these  normalized  queries 
to  search  the  Software  Database  for  reusable  modules  with  matching  normalized  spec¬ 
ifications.  This  search  results  in  either  a  single  match,  multiple  matches,  or  no  match. 
Assuming  only  one  match,  the  SDMS  retrieves  the  applicable  module.  When  multiple 
matches  occur,  the  designer  manually  intervenes  to  select  the  most  appropriate  module 
for  this  prototype.  After  all  required  modules  are  similarly  retrieved,  they  are  assembled 
to  create  the  executable  prototype. 

In  cases  where  no  match  occurs,  the  designer  can  either  hand  code  a  new  mod¬ 
ule  or  decompose  the  PSDL  component.  The  first  option  generates  a  unique  module 
required  for  this  prototype.  When  the  current  development  iteration  is  complete,  this 
new  module  is  included  in  the  CAPS  Software  Database.  The  second  option  requires 
manual  decomposition  of  the  composite  component  into  atomic  lower  level  PSDL 
components.  After  establishing  individual  specifications,  the  designer  reenters  each  new 
component  into  the  development  process  starting  with  the  Rewrite  System.  1  he  system 
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Figure  4,  Prototype  Development  with  CAPS 


also  retains  the  relationships  between  decompositions  to  insure  accurate  assembly  of  the 
retrieved  modules  during  the  final  stage.  |Ref.  3:  pp.  4,  16] 

3.  Prototype  System  Description  Language  (PSDL) 

The  design  of  PSDL  as  a  high-level  prototyping  language  associated  with  a 
rapid  prototyping  method  was  specifically  influenced  by  requirements  for  representing 
complex,  real-time  systems.  In  order  to  produce  a  reasonable  prototype,  PSDL  includes 
the  following  design  requirements: 

1.  PSDL  language  and  method  are  simple  and  easy  to  use. 
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2.  PSDL  creates  an  executable  prototype. 

3.  PSDL  supports  a  hierarchically  structured  prototype  which  simplifies  the 

prototyping  process. 

4.  PSDL  supports  retrieval  of  reusable  modules  from  a  database  using  precise 

specifications. 

5.  PSDL  uses  a  computational  model  that  explicitly  identifies  interactions 

between  components  which  encourages  modularization. 

6.  PSDL  contains  functional,  data  and  control  abstractions  for  representing 

the  critical  timing  constraints  of  operators.  [Ref.  6:  p.  10| 

The  PSDL  prototyping  method  encourages  a  top-down  design  strategy  that  focuses  the 
designer's  attention  on  the  critical  areas  or  attributes  only  of  the  system.  An  iterative 
process  decomposes  and  refines  these  critical  elements,  using  PSDL  abstractions  to  hide 
lower  level  programming  details.  Working  together  within  the  execution  support  envi¬ 
ronment,  the  PSDL  language  and  method  produce  a  modularized  computational  model 
that  contains  the  necessary  timing  constraints  to  simulate  the  critical  portions  of  the 
envisioned  system.  The  following  sections  explain  the  structure  of  the  computational 
model  and  describe  the  use  of  PSDL  abstractions.  Appendix  A  includes  a  complete 
listing  of  the  PSDL  grammar. 

a.  PSDL  Computational  Model 

The  PSDL  language  constructs  and  modular  design  rely  on  a  computational 
model  of  the  system  which  contains  operators  communicating  via  data  streams.  Math¬ 
ematically,  the  computational  model  is  an  augmented  graph  such  that 

G  =  (  V,  E,  T(v),  C(v)  ) 

where  V  equals  the  set  of  vertices  (operators),  E  equals  the  set  of  edges  (data  streams), 
T(v)  equals  the  maximum  execution  time  for  each  vertex  (v),  and  C(v)  equals  the  set  of 
control  constraints  for  each  vertex  (v).  Using  the  above  components,  the  PSDL  en¬ 
hanced  data  flow  diagram  represents  a  directed  graph  of  the  critical  aspects  of  the  envi¬ 
sioned  software  system,  including  both  the  timing  and  control  constraints. 
[Ref.  9:  pp.  8-9]  The  following  sections  describe  the  four  basic  components  of  the 
augmented  graph. 

(lj  Operators.  PSDL  operators  represent  cither  functions  or  state  ma¬ 
chines.  A  PSDL  operator  fires  when  triggered  by  cither  the  arrival  of  a  set  of  input  data 
values  or  the  arrival  of  a  periodic  timing  constraint.  When  an  operator  fires,  it  reads 
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one  data  value  from  each  input  stream  and  writes,  at  most,  one  computed  data  value 
onto  each  output  stream.  The  function  operator  computes  an  output  value  based  on  the 
current  input  data  values  only.  Since  the  state  machine  is  a  composite,  cyclical  operator, 
one  of  its  data  streams  acts  as  a  current  state  variable  and  controls  the  feedback  loop 
of  the  sub-operators.  Thus,  the  state  machine  computes  an  output  value  based  on  the 
current  input  data  values  and  the  current  value  of  its  internal  state  variable. 

PSDL  operators  are  also  identified  as  either  atomic  or  composite. 
Atomic  operators  represent  a  single  operation  and  cannot  be  decomposed  further. 
Composite  operators  represent  a  network  of  data  and  control  flow  lower  level  operators. 
This  network  contains  implied  precedence  relationships  between  the  sub-operators  such 
that 


if  the  output  from  operator  A  is  input  to  operator  B, 
then  operator  A  must  lire  before  operator  B. 

Thus,  a  composite  operator  is  decomposed  into  lower  level  representations  while  main¬ 
taining  the  required  precedence  relationships.  (Ref.  9:  p.  9] 

(2)  Data  Streams.  PSDL  data  streams  are  communication  links  between 
two  PSDL  operators,  the  producer  (output)  and  the  consumer  (input).  Each  stream  re¬ 
presents  a  sequential  flow  of  data  values  such  that 

if  data  value  A  is  generated  before  data  value  B, 
then  A  must  be  delivered  to  the  next  operator  before  B. 

This  "pipeline"  ordering  of  operators  is  tequired  for  real-time  computations 
(Ref.  10:  p.  127], 

These  data  streams  are  designed  as  either  data  llow  or  sampled 
streams.  A  data  How  stream,  similar  to  a  discrete  data  flow,  guarantees  that  each  data 
value  on  the  stream  is  delivered  and  acted  upon  only  once.  The  data  value  computed 
by  the  operator  thus  represents  a  unique  operation.  Data  flow  guarantees  that  data 
values  are  not  lost  or  repeated  by  utilizing  a  first-in  first-out  (FIFO)  queue.  This  format 
enforces  strict  timing  relationships  between  the  producer  and  consumer  to  insure  that 
the  queue  does  not  overflow  and  that  the  consumer  is  not  required  to  wait  for  input  data 
values. 
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A  sampled  stream,  similar  to  a  continuous  How.  guarantees  that  data 
values  can  be  entered  onto  or  delivered  from  a  data  stream  as  they  are  required  by  the 
operators.  A  sampled  stream  does  not  require  protection  against  lost  or  repeated  values 
since  only  the  most  recent  value  is  of  interest.  A  sampled  stream  utilizes  a  single  mem¬ 
ory  cell  which  is  updated  whenever  the  producer  generates  a  new  data  value.  This  for¬ 
mat  does  not  require  strict  timing  between  the  operators  since  a  producer  can  generate 
newr  values  whenever  or  as  often  as  the  consumer  requires.  [Ref.  9:  pp.  10-12] 

(3)  Timing  and  Control  Constraints.  When  considering  prototypes  for 
hard  real-time  systems,  the  timing  and  control  constraints  for  operator  firing  and  exe¬ 
cution  are  critical.  Within  the  computational  model,  each  time  critical  operator  includes 
a  maximum  execution  time  which  gives  the  worst  case  time  to  complete  execution  once 
the  operator  fires.  Critical  operators  can  also  include  conditional  control  constraints 
that  act  as  guards.  These  guards  stipulate  firing  conditions  for  an  operator,  conditions 
necessary  before  computed  values  are  output  onto  data  streams,  or  exception  situations. 
[Ref.  6:  p.  25] 

b.  PSDL  Abstractions 

The  PSDL  language  supports  three  types  of  abstractions  that  assist  in  de¬ 
veloping  a  simplified  but  flexible  model  of  the  critical  properties  of  a  complex  system. 
The  operator,  data  type  and  control  abstractions  represent  the  major  building  blocks  for 
constructing  the  PSDL  prototype. 

(l)  Operator  Abstractions.  PSDL  operator  abstractions  represent  either 
functional  or  state  machines.  Each  operator  has  a  PSDL  specification  and  implemen¬ 
tation  section.  The  specification  section  contains  attributes  which  describe  interfaces  to 
other  PSDL  components,  formal  and  informal  descriptions  of  the  operator's  obscnable 
behavior,  and  information  required  for  creating  queries  to  retrieve  the  reusable  modules 
from  the  software  database.  Specifically,  each  set  of  attributes  contains  generic  pa¬ 
rameters,  input,  output,  states,  exception  and  timing  information  as  shown  in  f  igure  5 
on  page  16.  Only  state  machine  abstractions  include  the  states  information,  which 
identifies  the  stale  variable  and  assigns  its  initial  value. 

The  operator  implementation  section  indicates  whether  an  operator 
abstraction  is  atomic  or  composite.  An  implementation  for  an  atomic  abstraction  con¬ 
tains  a  keyword  which  specifies  the  programming  language  and  the  name  of  the  retries  cd 
reusable  module  that  implements  this  operator.  An  implementation  for  a  composite 
abstraction  contains  a  set  of  attributes  which  includes  graph,  internal  data,  control 


OPERATOR  brain_tumor  treatment_system 
SPECIFICATION 

INPUT  patient_chart:  medical_history , 
treatment_swi tch:  boolean 

OUTPUT  treatmonL_Cinished:  boolean 
STATES  temperature:  real 
INITIALLY  37.0 
DESCRIPTION 

{  The  brain  tumor  treatment  system  kills  tumor  cells 
by  means  of  hyperthermia  induced  by  microwaves. 

END 

Figure  5.  PSDL  Operator  Specification 

constraints  and  an  informal  description  of  the  operator's  observable  behavior. 
Figure  6  on  page  17  provides  an  example  of  a  composite  abstraction.  The  PSDL  graph 
utilizes  an  enhanced  data  flow  diagram  which  is  based  on  the  PSDL  computational 
model's  augmented  graph.  The  PSDL  graph  combines  operator  specification  and  im¬ 
plementation  information  to  graphically  describe  the  operator's  abstractions  and  inter¬ 
faces.  [Ref.  9:  pp.  Id- 15] 

( 2j  Data  Type  Abstractions.  PSDL  data  type  abstractions  provide  a 
means  to  distinguish  between  the  prototype's  partial  representation  of  critical  operators 
and  the  operators'  actual  behavior  in  the  envisioned  system  as  a  whole.  The  PSDL 
prototype  language  enforces  strong  typing  by  requiring  that  both  pre-defined  and  user- 
defined  data  types  be  immutable.  This  rule  encourages  the  designer  to  clearly  and  ex¬ 
plicitly  define  an  operator's  type  within  the  context  of  the  prototype,  ignoring 
unnecessary  details.  Possible  data  types  include  the  subset  of  Ada®  prc-dclincd  types, 
user-defined  abstract  types,  PSDL  type  constructs,  and  the  PSDL  special  types  'l  l. ML 
and  EXCEPTION.  These  immutable  data  types  result  in  two  important  considerations 
when  developing  prototypes  lor  complex  systems: 

•  No  implicit  communication  occurs  between  operators. 

•  Common  interlaces  improve  comparison  with  the  envisioned  system  during  vali¬ 
dation  of  the  prototype. 

Each  data  type  has  a  PSDL  specification  and  implementation  section 
similar  in  content  and  format  to  the  operator  abstraction.  [Ref.  9:  pp.  13- lb) 
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DATA  STREAM  treatment  power:  real 
CONTROL  CONSTRAINTS 
OPERATOR  hyperthermia_system 
PERIOD  200  BY  REQUIREMENTS  shutdown 
OPERATOR  si.mulated_pati.ent 
PERIOD  200 

DESCRIPTION  {  paraphrased  output  } 


Figure  6.  PSDL  Operator  Implementation 


Figure  7  on  page  IS  and  Figure  S  on  page  19  provide  examples  of  a  data  type  specifi¬ 
cation  and  implementation. 

(3)  Control  Abstractions.  PSDL  control  abstractions  provide  a  means  to 
explicitly  describe  the  periodic  execution  of  operators.  These  abstractions  arc  repres¬ 
ented  as  a  set  of  control  constraints  within  the  PSDL  implementation  graph  of  each 
operator.  The  actual  or  scheduled  order  of  operator  execution  is  determined  by  the 
Static  Scheduler.  The  Scheduler  utilizes  these  constraints  to  recognize  the  precedence 
relationships  between  the  enhanced  data  How  diagrams  of  the  operators.  Control  con¬ 
straints  include  data  triggers,  periods,  conditionals,  1 IMER  and  EXCEPTION. 

The  primary  control  constraints  that  affect  all  PSDL  operators  are 
the  data  trigger  and  the  operator's  period.  All  operators  must  have  cither  a  period  or  a 
data  trigger,  or  both.  The  period  indicates  periodicity  of  execution  for  an  operator  while 
a  data  trigger  indicates  the  firing  frequency  of  an  operator.  Firing  frequency  can  be 
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TYFE  medical  history 
SPECIFICATION 

OPERATOR  get_tumor  diameter 
SPECIFICATION 

INPUT  patient_chart:  medicai_history , 
tumcr_location:  string 

OUTPUT  diameter:  real 
EXCEPTIONS  no_tumor 
MAXIMUM  EXECUTION  TIME  5  ms 
DESCRIPTION 

{  Returns  the  diameter  of  the  tumor  at  a  given  location, 
produces  an  exception  if  no  tumor  is  at  that  location. 

END 


KEYWORDS  patient_charts ,  medical_records ,  treatment_records , 
lab_records 
DESCRIPTION 

{  The  medical  history  contains  all  of  the  disease  and 
treatment  information  for  one  patient.  The  operations 
for  adding  and  retrieving  information  not  needed  by 
the  hyperthermia  system  are  not  shown  here. 

END 


Figure  7.  PSDL  Data  Type  Specification 


cither  periodic  (synchronous)  or  sporadic  (asynchronous).  Periodic  operators  are 
triggered  at  approximately  regular  intervals  which  insures  that  execution  is  completed 
between  the  beginning  of  each  period  and  its  deadline,  which  defaults  to  the  end  of  the 
period.  Sporadic  operators  are  implemented  by  their  periodic  equivalents  which  arc 
triggered  by  the  arrival  of  new  data  values.  The  following  examples  illustrate  the  PSDL 
data  triggers  and  their  interpretations: 

•  OPERATOR  s  TRIGGERED  BY  ALL  x.  y.  z 

•  OPERATOR  q  TRIGGERED  BY  SOME  a.  b. 

The  first  example  means  that  s  is  ready  to  lire  whenever  new  data  values  arrive  on  all 
three  input  streams  x,  y  and  z.  The  second  example  means  that  q  is  ready  to  fire  when 
any  one  of  the  data  values  a  or  b  arrive. 

Conditional  constraints  describe  the  execution  and  transmission  re¬ 
quirements  for  the  input  and  output  data  streams  of  an  operator.  Conditional  execution 
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tuple[tumor_desc:  raap[from:  string,  to:  real], 
OPERATOR  get_tumor_diameter 
IMPLEMENTATION 
GRAPH 


PATIENT-CHART 
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TUNOR-LOCAT I  ON 


NAP. FETCH 
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DATA  STREAM  td:  tumor_descr 
CONTROL  CONSTRAINTS 
OPERATOR  map. fetch 

EXCEPTIONS  no_tumor  IF  not(map. has( tumor_location,  td)) 


Figure  8.  PSDL  Data  Type  Implementation 

of  an  operator  requires  an  IF  predicate  along  with  the  data  trigger.  This  conditional 
predicate  must  be  satisfied  before  the  operator  is  triggered  and  execution  begins.  Con¬ 
ditional  transmission  of  an  operator's  output  requires  an  IF  predicate.  This  condition 
must  be  satisfied  before  an  operator  can  output  a  data  value.  The  following  examples 
illustrate  how  these  constraints  appear  in  the  PSDL  implementations: 

•  OPERATOR  x  TRIGGERED  IF  v  ■  critical 

•  OPERATOR  x  OUTPUT  z  IF  1  <  z  and  z  <  max 

where  x  is  the  operatorjd,  y  is  the  input  data  stream  value  and  z  is  the  output  data 
stream  value. 

The  TIMER  represents  a  unique  type  of  state  machine  which  func¬ 
tions  similar  to  a  stopwatch.  An  operator  TIMER  can  be  used  to  record  the  length  of 


time  between  events  or  the  length  of  time  spent  in  a  given  state.  Control  of  the  TI ME  If 
is  local  to  the  component,  whether  atomic  or  composite,  in  which  it  is  declared.  Only 
the  TIMER  value  can  be  transmitted  via  a  data  stream  to  outside  of  the  local  compo¬ 
nent.  TIMER  utilizes  four  primitive  operations  which  include  READ  the  current  value. 
START  the  timer,  STOP  the  timer  and  RESET  the  timer  with  a  value  equal  to  zero. 

EXCEPTION  represents  unique  situations  that  are  either  system  or 
user-defined.  The  underlying  operating  system  raises  a  system-defined  EXCEPTION 
when  extraordinary  situations  preclude  continued  execution  of  the  program.  A  user- 
defined  EXCEPTION  alerts  the  prototype  demonstrator  to  situations  that  indicate  crit¬ 
ical  timing  or  control  constraints  were  not  satisfied  during  execution.  For  example,  the 
control  constraint 

OPERATOR  d  EXCEPTION  f  IF  e  >10 

transmits  the  EXCEPTION  named  f  on  the  output  streams  of  d  instead  of  the  value 
computed  by  d  if  the  value  of  e  is  greater  than  10.  [Ref.  9:  pp.  1 6-2 1 J 

(4)  PSDL  Timing  Constraints.  Hard  real-time  systems  differ  from  his¬ 
torical  systems  primarily  due  to  timing  constraints  which  control  proper  execution  of  the 
system.  Control  in  this  context  refers  to  the  critical  riming  relationships  between  the 
operators.  The  three  fundamental  timing  constraints  are  maximum  execution  time 
(MET),  maximum  response  time  (MRT),  and  minimum  calling  period  (MCP).  The  de¬ 
signer  specifies  these  critical  constraints,  using  worst  case  time  scenarios,  in  the  PSDL 
specification  and  implementation  sections  of  the  PSDL  module. 

Within  the  PSDL  specification  section  the  designer  specifies  one  or 
more  of  the  above  three  constraints  depending  on  whether  the  operator  is  periodic  or 
sporadic.  All  time  critical  operators  require  an  MET  which  specifies  an  upper  bound 
on  the  length  of  time  between  that  operator's  execution  initiation  and  its  completion. 
However,  the  MET  docs  not  include  additional  time  for  potential  execution  scheduling 
delays.  Any  operator  may  also  include  an  MRT  constraint  whose  interpretation  differs 
slightly  depending  on  the  type  of  operator.  Tor  peiiodic  operators,  MRT  specifies  the 
upper  bound  on  the  amount  of  time  between  the  beginning  of  a  period  and  the  instance 
of  time  when  that  operator  places  the  last  computed  data  value  onto  its  output  streams 
during  that  same  period.  For  sporadic  operators,  MRT  specifies  an  upper  bound  on  the 
amount  of  time  between  the  arrival  of  a  new  data  value,  or  set  of  data  values,  and  the 
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instance  of  time  when  that  operator  places  the  last  computed  data  value  onto  its  output 
streams,  in  response  to  the  arrival  of  a  new  data  value  or  set  of  data  values.  In  hoih 
cases,  MRT  considers  and  includes  potential  execution  scheduling  delays.  Any  sporadic 
operator  with  an  MRT  requires  an  MCP.  The  MCP  specifies  a  lower  bound  on  the 
amount  of  time  between  the  arrival  of  one  set  of  input  data  values  and  the  arrival  of  the 
next  set  for  that  operator.  Thus,  the  MCP  indicates  the  minimum  amount  of  time  that 
must  elapse  between  firings  of  the  sporadic  operator. 

Within  the  PSDL  implementation  section  the  designer  specifies  the 
less  straightforward  or  implicit  timing  constraints.  These  constraints  include  the  PSDL 
constructs  for  event  controlled  timers,  triggering  and  output  conditions.  A  PSDL 
TIMER  controls  execution  of  an  operator  by  maintaining  the  timing  functions  required 
to  support  the  conditional  specifications  for  that  operator.  Triggering  and  output  con¬ 
ditions  control  operator  execution  by  enforcing  conditional  requirements  which  must  be 
met  before  firing  of  or  output  by  that  operator  can  occur.  [Ref.  9:  pp.  23-2-4] 

C.  KODIYAK  TRANSLATOR  GENERATOR 

Utilization  of  CAPS  during  rapid  prototyping  of  hard  real-time  systems  produces  a 
PSDL  prototype  source  program  of  the  envisioned  software  system.  The  ESS's  Static 
Scheduler  must  identify  and  extract  the  critical  operators  and  their  associated  timing 
constraints  from  this  PSDL  source  program  before  creating  the  static  schedule.  The 
Kodiyak  automatic  translator  generator  is  the  tool  which  provides  the  Static  Scheduler 
with  the  capability  to  process  the  PSDL  source  program.  This  section  begins  with  a 
general  description  of  the  Kodiyak  tool  and  concludes  with  its  specific  application  for 
the  Static  Scheduler. 

Kodiyak  is  an  attribute  grammar  (AG)  based  tool  which  automatically  generates  a 
translator.  The  AG  approach  provides  a  way  for  the  designer  to  assign  meanings  to 
each  input  string  in  a  context-free  manner.  Thus,  the  AG-buscd  source  code  contains 
application  specific  grammar  and  attribute  equations  written  in  Kodiyak.  The  compiled 
output  is  a  translator  in  C  language.  The  translator  parses  each  input  string  and  places 
its  translation  in  a  derivation  tree  whose  structure  is  based  on  the  specified  equations. 
The  structure  of  the  tree,  therefore,  provides  the  meaning  for  each  string.  The  three 
sections  ol  the  Kodiyak  AG  tool  arc  described  brielly  in  the  following  paragraphs  and 
are  illustrated  in  Figure  9  on  page  22.  Detailed  information  on  modifying  this  tool  for 
a  specific  application  are  found  in  References  1 1  and  12. 
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LEXICAL  SCANNER  SECTION: 


Terminal  Symbols 


Regular  Expressions 


OPERATOR 

MAX_EXEC_TIME 


: operator  OPERATOR 
:  maximuni[  ]execution[  ]time 
| MAXIMUM[  ]EXECUTION[  ]TIME 


where  "|"  equals  "or"  and  "[  ]"  equals  "any  character". 


ATTRIBUTE  DECLARATIONS  SECTION: 
Grammar  Symbols 


Attributes 


operator 

max_exec_time 

ID 


{  trn:  string;  }  ; 

{  trn:  string;  }  ; 

{  %text:  string;  }  ; 


where  "trn"  equals  "translation". 


ATTRIBUTE  GRAMMAR  SECTION: 


Grammar  Symbols 


max_exec_t  itne 


Syntax  {  Definition  Equations  } 


: MAXJEXEC_TIME  time 
{  inax_exec_time.  trn  = 

[  "MET  ", i2s( time. trn)  ]  ;  } 

:  INTEGER_LITERAL  opt_unit 
{  time.  value=s2i( INTEGER_LITERAL.  %text) 
*  opt_unit.  value; 
time. trn=i2s(time. value); } 

: MICROSEC 

{  unit. trn  =  " l";  ) 

IMS 

{  unit,  trn  =  "lOOO";  } 


igurc  9.  Kodiyak  A<J  examples 


1.  Lexical  Scanner 

As  the  initial  section  of  the  translator,  the  lexical  scanner  contains  a  list  of 
statements  which  describe  each  named  terminal  symbol  of  the  target  language  as  shown 
in  Figure  9  on  page  22.  The  primary  function  of  these  statements  is  to  define  a  set  of 
regular  expressions  which  represent  expected  text  within  the  input  source  program.  .As 
the  translator  reads  the  input  program,  the  lexical  scanner  sequentially  locates  regular 
expressions  that  match  terminal  symbols.  When  a  match  occurs,  the  input  text  is  deleted 
and  is  replaced  with  the  terminal  symbol.  [Ref.  11:  p.  3] 

2.  Attribute  Declarations 

The  second  section  of  the  translator,  the  attribute  declarations,  contains  a  list 
of  statements  which  further  describes  both  terminal  and  non-terminal  grammar  symbols 
as  shown  in  Figure  9  on  page  22.  Each  statement  names  the  attribute  associated  with 
a  grammar  symbol  and  dciincs  the  attribute's  type,  either  string  or  integer.  String  types 
have  arbitrary  length  and  may  be  concatenated.  The  range  of  integers  depends  solely 
on  local  machine  capabilities.  Most  non-terminal  symbols  require  an  attribute  declara¬ 
tion  while  named  terminal  symbols,  such  as  ID,  are  included  only  if  necessary  for  accu¬ 
rate  translation.  [Ref.  11:  p.  7-9| 

3.  Attribute  Grammar 

The  final  section  of  the  translator,  the  attribute  grammar,  contains  a  list  of 
statements  as  shown  in  Figure  9  on  page  22  which  define  the  syntax  and  semantics  of 
the  target  language  as  a  grammar  tree.  Each  statement  defines  a  grammar  symbol  as  a 
combination  of  root  symbols  using  associative  attribute  equations.  Items  to  the  left  of 
the  colon  represent  the  grammar  symbols  while  expressions  to  the  right  of  the  colon 
represent  the  grammar's  syntax  followed  by  attribute  definition  equations  in  {  braces  }. 
In  the  example  used,  a  translation  might  be  MET  9  MICROSEC.  If  the  input  text 
stated  "9  MS",  then  the  translation  would  be  MET  9,000  MICROSEC.'. 
[Ref.  11:  pp.  9-10[ 

In  this  thesis,  the  Kodiyak  tool  is  specifically  tailored  as  a  PSL>L  processor  for 
the  Static  Scheduler.  The  AG  source  code  contains  those  specific  PSDL  giammar  and 
attribute  equations  written  in  Kodiyak  which  define  the  critical  operators  and  their 
timing  constraints  and  precedence  relationships.  The  compiled  C  language  processor 
then  locates  and  extracts  operators  and  timing  information  froi  t  the  original  PSDL 
source  program  that  are  required  by  the  Static  Scheduler.  Chapter  IV  contains  a 


detailed  description  of  the  l’SDL  grammar  and  attributes  that  were  modified  specifically 
for  the  Static  Scheduler. 

D.  ADA  PROGRAMMING  LANGUAGE 

From  the  plethora  of  computer  programming  languages  available  and  familiar  to 
software  programmers,  the  designers  of  CAPS  selected  Ada®  as  the  most  appropriate 
programming  language.  Two  factors  reinforced  their  selection: 

1.  DOD's  elForts  to  standardize  software,  and 

2.  Ada®'s  constructs  for  representing  complex  and  embedded  software  systems. 

With  the  increased  demand  for  complex  real-time  systems,  the  DOD  recognized  that  the 
design  and  management  of  these  systems  required  a  new  development  approach.  DOD 
initiated  development  of  a  programming  language  incorporating  new  software  engineer¬ 
ing  principles  and  including  capabilities  designed  specifically  for  complex  systems.  As  a 
result,  implementation  of  CAPS  in  Ada®  will  provide  a  computer-aided  rapid  prototyp¬ 
ing  tool  compatible  with  and  directly  related  to  the  development  of  future  complex 
software  systems.  [Ref.  1:  pp.  3-4] 

Early  Ada®  designers  recognized  that  complex  software  systems  required  parallel 
processing,  real-time  control,  exception  handling,  and  unique  input/output  (1,0)  control 
[Ref.  1:  p.  16J.  From  these  basic  requirements  the  designers  identified  a  programming 
style  and  its  associated  language  constructs  that  are  fundamental  to  the  development  of 
complex  systems  containing  critical  timing  constraints.  At  the  highest  level,  the  recom¬ 
mended  programming  style  includes  conventions  for  organizing  program  units  and  for 
naming  entities.  Proper  use  of  Ada®'s  program,  task  and  package  units  insures  a  mod¬ 
ular  design  supported  by  separate  compilation  of  individual  units  and  by  data  ab¬ 
stractions.  The  preferred  Ada®  naming  conventions  for  all  user-defined  entities  create 
software  code  that  is  easily  understood  and  self-documenting.  The  Ada®programming 
language  includes  a  pre-defined  language  environment  that  contains  extensive  data 
types,  calendar; timing  functions,  system  exceptions,  and  several  levels  of  1,0  operations. 
Hou'ever,  Ada®programming  principles  also  stress  uscr-delined  data  types,  exceptions, 
and  1,0  operations  to  insure  precise  implementations  and  consistent,  self-documenting 
code. 

At  a  lower  level,  Ada®  constructs  for  task  program  units  containing  rendezvous 
operations  are  integral  concepts  for  prototyping  real-time  systems.  The  rendezvous 
constructs  ENTRY  and  ACCEPT  provide  explicit  synchronization  between  two  parallel 


tasks,  supporting  both  concurrency  of  operation  and  precedence  relationships  between 
time  critical  operators.  Instantiation  of  generic  program  units  provides  the  necessary 
environment  for  creating  the  prototype's  abstract  representation  of  the  envisioned  sys¬ 
tem.  Chapter  IV  of  this  thesis  describes  the  application  of  these  constructs  during  im¬ 
plementation  of  the  Static  Scheduler. 

E.  HYPERTHERMIA  MODEL 

During  the  initial  conceptual  research  for  the  CAPS  [Ref.  6],  the  hyperthermia  sys¬ 
tem  was  used  as  a  model  for  studying  a  hard  real-time  system.  This  model  provides  a 
dynamic  environment  with  critical  timing  constraints,  but  is  also  small  enough  to  easily 
understand  and  manipulate.  The  hyperthermia  system  is  described  as 

..  a  medical  device  for  treating  tumors  .  .  ,  which  uses  a  microwave  generator  con¬ 
nected  to  a  fine  tuner  and  matching  control  system.  The  hyperthermia  system  uses 
microwave  energy  to  produce  and  deliver  controlled  local  therapeutic  healing  di¬ 
rectly  to  tumors  for  effective  and  sale  treatment  of  cancer.  A  computerized  control 
system  adjusts  power  output  automatically  to  maintain  the  therapeutic  temperature 
in  accordance  with  the  established  patient  treatment  plan.  [Ref.  13:  p.  11] 

For  the  hyperthermia  system,  the  designer  must  determine  which  subsystems  and 
attributes  are  required  by  the  prototype  to  accurately  simulate  the  envisioned  system. 
The  designer  of  a  prototype  would  only  be  concerned  with  subsystems  that  receive 
temperature  readings  from  sensors  and  that  generate  commands  to  modify  or  terminate 
the  treatment.  The  following  critical  requirements  [Ref.  13:  p.  13|  were  identified: 

1.  Power  must  drop  to  zero  within  300  ms  after  turning  off  the  system. 

2.  Temperature  must  remain  between  42.2  and  42.6  degrees  centigrade. 

3.  Temperature  must  never  exceed  42.6  degrees  centigrade. 

4.  System  must  stabilize  within  5  minutes  after  starting  treatment. 

5.  System  must  shutdown  automatically  when  the  temperature  is  above  42.4  degrees 
centigrade  for  45  minutes. 

The  resulting  I’SDL  prototype  for  the  hyperthermia  system,  based  on  the  above  re¬ 
quirements,  is  presented  in  Appendix  13.  Sections  from  this  sample  prototype  program 
are  used  throughout  this  thesis  to  clarify  an  idea  or  provide  examples  for  the  imple¬ 
mentation. 


III.  STATIC  SCHEDULER  CONCEPTUALIZED 
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A.  INTERNAL  ENVIRONMENT 

Chapter  II  of  this  thesis  described  CAPS  as  an  effective  and  efficient  tool  for  creat¬ 
ing  an  executable  prototype  of  a  hard  real-time  system.  Rapid  construction  and  vali¬ 
dation  of  a  prototype  require  an  execution  support  environment  that  automates  the 
many  time-consuming  tasks  involved  with  developing  the  design  up  through  analyzing 
the  performance  of  the  prototype.  Although  the  ESS  represents  only  one  component 
of  the  CAPS  prototyping  tool,  it  is  the  primary  factor  that  differentiates  CAPS  from 
manual  prototyping  tools.  The  ESS  provides  automated  control  and  interface  capabili¬ 
ties  that  allow  the  system  to  save  current  state  information  when  run-time  discrepancies 
arc  noted  and  to  execute  modified  versions  of  the  prototype.  [Ref.  6:  p.  7].  These  ca¬ 
pabilities  are  essential  to  realize  time  and  cost  savings  and  to  increase  user  confidence 
that  the  system's  design  is  feasible. 

The  ESS  contains  a  Dynamic  Scheduler,  a  Static  Scheduler,  and  a  Translator.  As 
conceptualized  by  the  author  for  this  thesis,  Figure  10  on  page  27  illustrates  the  ESS 
subsystems'  external  interfaces  to  other  components  of  CAPS  and  the  interactions 
within  the  ESS  itself.  The  ESS  utilizes  four  external  interfaces  from  outside  the  ESS. 
Initially,  a  command  from  the  LT  to  the  Dynamic  Scheduler  activates  the  ESS  when  the 
designer  requests  execution  of  the  PSDL  prototype.  Second,  the  Translator  and  the 
Static  Scheduler  require  access  to  the  PSDL  prototype  source  program  created  jointly 
by  the  designer  and  the  user.  Third,  the  Combiner  Linker  Exporter  (CLE)  receives, 
compiles  and  links  ttie  Ada®  source  code  from  the  Translator  and  the  Static  Scheduler. 
The  executable  code  generated  by  the  CLE  becomes  input  to  the  Dynamic  Scheduler  for 
run-time  execution.  The  final  interface  from  the  Dynamic  Scheduler  to  the  L  I  provides 
prototype  execution  statistics,  analysis  and  error  message  information  direct  to  the  de¬ 
signer. 

The  first  objective  of  this  Chapter  is  a  description  of  the  ESS  subsystems.  A  brief 
introduction  to  the  basic  functions  of  the  Dynamic  Scheduler  and  the  Translator  pio- 
vides  a  general  survey  of  the  execution  environment.  Emphasis  is  placed  on  the  inter¬ 
laces  between  each  of  these  subsystems  and  especially  with  the  Static  Scheduler.  The 
primary  objective  of  this  Chapter  is  to  provide  a  detailed  description  of  the  Static 
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Figure  10.  Execution  Support  System  Interfaces 


Scheduler.  This  description  covers  the  functions  and  responsibilities  that  the  Static 
Scheduler  must  accomplish  to  create  a  static  schedule  for  time  critical  operators. 


1.  Dynamic  Scheduler 


The  conceptualized  design  for  the  Dynamic  Scheduler  utilized  in  this  thesis  de¬ 


rives  directlv  from  Reference  14  and  as  initially  conceived  in  Reference  4.  The  Dvnamic 


Scheduler  fulfills  two  major  roles  for  the  CATS.  First,  the  Dynamic  Scheduler  exercises 
the  prototype  which  is  a  fundamental  requirement  of  a  rapid  computer-aided  prototyp¬ 
ing  system.  Second,  prompt  feedback  from  the  Dynamic  Scheduler  to  the  LI  allows  the 
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designer  and  the  user  to  assess  the  prototype's  execution  performance.  In  order  to  per¬ 
form  these  roles,  the  Dvnamic  Scheduler  coordinates  the  functions  of  the  entire  LSS. 


In  its  first  role,  the  Dynamic  Scheduler  acts  as  the  primary  link  between  the 
CAPS  UI  and  the  ESS.  When  the  designer  completes  the  PSDL  prototype  source  pro¬ 
gram,  a  request  from  the  LI  (or  a  potential  subsystem  of  the  LI)  to  execute  the  PSDL 
prototype  is  received  by  the  Dynamic  Scheduler.  The  Dynamic  Scheduler  in  turn  in¬ 
vokes  the  Translator  and  the  Static  Scheduler,  and  initiates  procedures  which  pre-load 
data  stream  buffers  for  the  Translator.  The  Translator  transforms  the  PSDL  prototype 
program  into  an  executable  Ada®  program  while  the  Static  Scheduler  provides  a  linear 
static  schedule  for  time  critical  operators.  An  Ada®-compiled  implementation  of  the 
prototype  then  becomes  an  input  to  the  Dynamic  Scheduler.  After  successful  com¬ 
pletion  of  these  prw-'\ecution  functions,  the  Dynamic  Scheduler  provides  all  run-time 
executive  activities  while  exercising  the  prototype. 

As  the  ESS  driver  program,  the  Dynamic  Scheduler  has  two  main  responsibil¬ 
ities.  First,  it  schedules  operators  without  timing  constraints  that  were  not  included  in 
the  static  schedule.  The  Dynamic  Scheduler  receives  an  input  file  from  the  Static 
Scheduler  containing  these  unscheduled  operators.  Since  the  Static  Scheduler  uses  worst 
case  times  (METs)  for  scheduling  the  critical  operators,  on  the  average  these  operators 
will  not  utilize  the  entire  allotted  time  slots.  The  Dynamic  Scheduler  identifies  this  spare 
capacity  as  it  occurs  and  schedules  operators  without  timing  constraints  during  the  time 
remaining.  In  some  cases  the  operators  so  scheduled  may  not  complete  execution  during 
this  time  slot.  The  Dynamic  Scheduler  must  then  preempt  the  operator's  execution  and 
abandon  the  entire  operation  before  the  next  pre-scheduled  critical  operator  must  begin 


execution. 


The  second  ESS  responsibility  of  the  Dynamic  Scheduler  provides  run-time  ex¬ 
ception  handling  and  hardware,  operator  interrupts.  EXCEPTION'S  are  raised  from  the 
Translator  as  either  dataflow  overloads  when  an  operation  attempts  to  write  to  a  buffer 
that  is  full  or  dataflow  underloads  when  an  operation  attempts  to  read  from  an  empty 
buffer.  EXCEPTION'S  arc  raised  from  the  Static  Scheduler  when  a  critical  operator  ex¬ 
ceeds  its  worst  ease  (MET)  time  slot  or  validity  checks  on  constraint  values  indicate  a 
static  schedule  is  not  feasible.  In  all  of  these  cases,  execution  of  the  prototype  will  stop 
and  an  applicable  error  message  is  displayed  at  the  L  I.  The  Dynamic  Scheduler  must 
also  handle  conventional  interrupts,  such  as  a  <  cr>  C  from  the  user  to  abort  execution 
or  an  equipment  failure. 
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Future  enhancements  identified  in  addition  to  the  current  Dvnamic  Scheduler 


design  would  provide  debugging  capabilities  and  statistical  information.  During  exe¬ 
cution  of  the  prototype,  the  debugging  capabilities  would  trace  relevant  information 
concerning  operator  execution.  Computed  values  and  their  associated  input  and  output 
times  would  display  a  record  of  events  that  occur  during  execution.  Statistical  informa¬ 
tion  collected  during  execution  would  include  frequency  of  operator  bring,  quantity  of 
EXCEPTION'S  occurring,  and  statistical  data  on  timing  parameters  for  critical  opera¬ 
tors.  [Ref.  4:  pp.  10-11]  When  combined,  these  two  enhancements  would  provide  the 
designer  and  the  user  with  precise  information  for  measuring,  analyzing  and  validating 
tiie  prototype's  performance. 

2.  Translator 

The  conceptualized  design  for  the  Translator  utilized  in  this  thesis  derives  di¬ 
rectly  from  Reference  12  and  as  initially  conceived  in  Reference  4.  The  Translator  s 
primary  responsibility  is  the  translation  of  the  PSDL  prototype  source  program  into  an 
executable  Ada3  program  that  simulates  the  behavior  of  the  prototype.  The  Translator 
accomplishes  this  translation  by  utilizing  a  version  of  the  Kodiyak  translator  generator 
specifically  tailored  for  this  application.  The  Translator  invokes  the  AG  translator  pro¬ 
gram  which  semantically  parses  the  PSDL  program  statements  into  their  Ada®  program 
representations.  The  translator  contains  a  list  of  PSDL  grammar  statements  with  their 
associated  attribute  definition  equations  that  represent  the  corresponding  Ada®gram- 
mar.  These  equations  define  the  semantics  of  the  translation  using  a  structured  grammar 
tree  approach. 

Augmentation  code  for  PSDL  atomic  operators  is  embedded  within  the  attri¬ 
bute  definition  equations.  These  augmentations  implement  the  PSDL  data  streams, 
PSDL  operator  conditional  constraints  and  PSDL  TIMER  functions.  Both  sampled  and 
data  How  stream  augmentations  are  implemented  with  individual  buffers  containing  one 
computed  value  for  each  stream.  I’SDL  operator  triggering  conditions  and  output 
guards  are  implemented  by  the  equivalent  Ada®  semantics.  A  PSDL  TIMER  is  imple¬ 
mented  using  the  CLOCK  function  from  the  standard  Ada®  library  package  CALEN¬ 
DAR. 

During  the  early  prototype  design  phase,  any  PSDL  composite  operators  arc 
decomposed  into  atomic  operator  networks.  Reusable  modules  from  the  CAPS  Data¬ 
base,  considered  as  Ada®  program  units  for  this  thesis,  are  inserted  as  the  implementa¬ 
tion  code  for  these  operators.  The  augmentation  code  described  above,  combined  with 
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these  Ada®  implementations,  produces  the  prototype's  Ada3  souicc  code.  The  Chi; 
compiles  this  source  code  and  links  it  with  the  compiled  static  schedule  to  genet  ate  'he 
executable  Ada®  program.  This  executable  program  then  becomes  the  input  to  the 
Dynamic  Scheduler  for  execution  of  the  prototype. 

B.  THE  STATIC  SCHEDULER 

The  conceptualized  design  (or  the  Static  Scheduler  utilized  in  this  thesis  derives  di¬ 
rectly  from  Reference  15  and  as  initially  conceived  in  Reference  4.  The  primary  devel¬ 
opment  emphasis  for  CAPS  was  computer-aided  rapid  prototyping  for  hard  real-time 
systems.  By  automating  many  of  the  time-consuming  tasks  of  conventional  rapid  pro¬ 
totyping  tools,  the  ESS  and  the  SDMS  differentiate  the  CAPS  from  its  manual  or  semi- 
automated  counterparts.  But  the  Static  Scheduler  subsystem  of  the  ESS  alone  represents 
the  single  most  important  component  of  _/\PS  as  the  basic  requirement  for  computer- 
aided  rapid  prototyping  of  hard  real-time  systems.  The  Static  Scheduler  specifically  ad¬ 
dresses  only  those  operators  with  critical  timing  constraints  whose  precise  performance 
determine  whether  the  system,  as  designed,  will  meet  the  required  timing  specifications. 

As  conceptualized,  the  primary  purpose  of  the  Static  Scheduler  is  creation  of  a  static 
schedule  which  gives  the  precise  execution  order  and  timing  of  operators  with  hard 
real-time  constraints  in  such  a  manner  that  all  timing  constraints  are  guaranteed  to  be 
met  [Ref.  4:  p.  7].  Assuming  that  such  a  schedule  is  feasible  given  the  system  specifi¬ 
cations.  the  static  schedule  contains  the  pre-ailocated  starting  time  and  execution  time 
for  each  critical  operator.  This  structure  implicitly  denotes  the  precedence  relationships 
between  the  operators.  Without  the  benefit  of  a  Static  Scheduler,  execution  of  the  pro¬ 
totype  would  rely  on  basic  control  flow  and  processor  scheduling  as  currently  utilized  in 
the  majority  of  software  systems.  Rapid  prototyping  in  general  would  benefit  from 
CAPS  without  a  static  schedule.  However,  the  Static  Scheduler  provides  CAPS  with  the 
unique  capability  required  to  realize  increased  gains  in  designer  productivity  and  system 
reliability  during  development  of  hard  real-time  systems. 

The  remainder  of  this  Chapter  provides  implementation  guidelines  describing  how 
the  Static  ochcduicr  functions  as  conceptualized  in  Reference  15  and  by  this  author. 
The  implementation  design  in  this  thesis  addresses  a  single  processor  application  only. 
'1  he  impact  on  or  modification  to  this  design  when  multi-processors  and  concurrent 
processing  are  utilized  will  not  be  addressed  explicitly.  Data  flow  Diagrams  (DTDs)  in 
Appendix  C  illustrate  the  conceptualized  design  for  implementation  of  the  Static 
Scheduler.  The  1st  level  DI  D  presents  a  general  description  of  the  Static  Scheduler 


while  the  lower  level  DTDs  contain  more  specific  implementation  guidelines.  The  cur¬ 
rent  discussion  addresses  the  1st  and  2nd  level  DFDs  and  outlines  assumptions  that  were 
made  to  define  the  scope  of  the  implementation  guidelines. 

1.  Statie  Scheduler  1st  Level  DFD 

The  1st  Level  DFD  in  Appendix  C  outlines  the  five  major  functions  of  the 
conceptualized  Static  Scheduler  (Ref.  15].  The  initial  input  to  the  Static  Scheduler  is  a 
text  file  containing  the  PSDL  prototype  program  created  jointly  by  the  designer  and  the 
user.  An  intermediate  output  to  the  Dynamic  Scheduler  is  a  text  file  containing  the 
non-time-critical  operators  that  were  extracted  from  the  PSDL  program  together  with 
the  time  critical  operators.  The  final  output  from  the  Static  Scheduler  to  the  CLE  is  an 
Ada®  source  file  containing  the  static  schedule.  The  CLE  compiles  and  links  this  pro¬ 
gram  to  the  Translator's  compiled  Ada®  program.  This  combined  program  is  the  exe¬ 
cutable  Ada®  piogram  used  by  the  Dynamic  Scheduler  to  demonstrate  the  prototype's 
performance.  The  following  sections  describe  the  functions  performed  by  each  compo¬ 
nent  of  the  1st  level  DFD  and,  in  the  process,  provide  an  introduction  to  the  lower  level 
DTDs. 

a.  "Read_PSDL" 

Following  initiation  by  the  Dynamic  Scheduler,  the  Static  Scheduler's  first 
major  function  is  reading  and  processing  the  PSDL  prototype  program.  Although  the 
Translator  performs  a  similar  but  extensive  process  for  the  entire  PSDL  program,  the 
Static  Scheduler  requires  only  that  information  which  identifies  critical  operators  along 
with  their  associated  timing  constraints  and  the  link  statements  which  syntactically  de¬ 
scribe  the  PSDL  graphs.  A  specifically  tailored  version  of  the  AG-based  Kodiyak  tool 
for  the  Static  Scheduler  identifies  and  extracts  this  information  only  from  the  PSDL 
source  program.  This  process  creates  a  sequential  text  file  containing  operator  identifi- 
eis,  timing  information  and  link  statements. 

As  conceptualized,  implementation  of  the  current  design  is  based  on  two 
assumptions.  First,  this  design  assumes  that  the  PSDL  prototype  program  is 
syntactically  correct.  This  implies  that  each  line  begins  with  a  PSDL  keyword  or 
reserved  word.  Second,  this  design  assumes  that  the  designer  structured  the  PSDL 
prototype  program  using  a  top-down  design.  This  implies  that  the  program  begins  with 
the  highest  level  and  then  decomposes  all  composite  operators,  with  the  last  (or  lowest) 
level  being  the  Ada®  implementation  modules.  These  assumptions  are  realistic  in  that 


PSDL  encourages  the  designer's  use  of  a  structured,  modular  architecture  and  also  (hat 
the  UJ  will  include  a  syntax-directed  editor. 
b.  "  Pre-Process  JTile" 

Alter  the  AG  processor  creates  the  output  text  file,  the  Static  Scheduler's 
next  major  function  is  sorting  the  contents  of  this  file  and  performing  basic  validity 
checks  on  pertinent  information.  The  input  text  file  is  a  sequentially  ordered  file  con¬ 
taining  all  required  information  as  it  was  extracted  from  the  PSDL  program.  This  in¬ 
formation  must  be  divided  into  three  separate  files  based  on  its  destination  or  additional 
processing  required.  The  Non-Crits  file  contains  a  sequential  list  of  all  non-time-critical 
operator  identifiers  which  becomes  an  intermediate  input  to  the  Dynamic  Scheduler. 
The  Dynamic  Scheduler  schedules  these  operators  during  execution  of  the  prototype  as 
excess  time  becomes  available.  The  Operator  n!-’  contains  all  critical  operator  identifiers 
and  their  associated  timing  constraints.  This  file  is  organized  as  an  array  of  records. 
Each  record  contains  fields  for  the  operator  identifier  and  the  numeric  values  of  its  M  ET. 
MRT,  MCP,  period  and  FINISII_WITHIN.  The  Links  file  contains  the  link  statements 
which  syntactically  describe  the  PSDL  implementation  graphs.  This  file  is  also  organ¬ 
ized  as  an  array  of  records.  Each  record  contains  fields  for  the  data  stream  identifier 
which  communicates  between  the  two  operators,  the  producer  operator  identifier  and  the 
numeric  value  of  its  MET,  and  the  consumer  (user)  operator  identifier.  The  derivation 
of  these  link  statements  appears  in  the  section  "Sort_Topological". 

During  this  phase,  the  Static  Scheduler  also  performs  basic  validity  checks 
on  the  timing  constraints  contained  in  the  critical  operator  file.  At  a  minimum,  three 
validity  checks  performed  at  this  stage  will  increase  the  probability  of  creating  a  feasible 
schedule  during  the  later  stages.  The  first  check  verifies  that  an  operator  record  con¬ 
taining  an  MCP  value  also  contains  an  MRT  value.  If  the  MRT  is  missing,  it  is  calcu¬ 
lated  as  either  (  MRT  equals  F1NISI  MVTfHIN  )  or  (  MRT  equals  MET  ).  A  second 
check  verifies  that  an  operator's  MET  value  does  not  equal  its  period  value,  if  a  period 
is  present  in  the  record.  A  third  check  verifies  that  an  operator's  MET  value  is  less  than 
its  M  R I  value.  [Ref.  16:  p.  6]  In  all  three  cases,  if  any  one  of  the  checks  (ails  an  EX¬ 
CEPTION  will  be  raised  and  an  appropriate  error  message  submitted  to  the  L’l.  T  he 
significance  of  these  validity  checks  will  become  apparent  in  the  section  for 
"BuiidJ  larmonic_Blocks". 

As  conceptualized,  implementation  of  the  current  design  is  based  on  two 
assumptions,  first,  this  design  assumes  that  critical  operators  will  always  include  an 
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MET  value.  If  this  value  is  not  present,  the  operator  is  assumed  non-tirne-critical  and 
is  delivered  to  the  Dynamic  Scheduler.  Second,  this  design  assumes  that  all  timing  con¬ 
straints  are  non-negative  integer  values.  These  assumptions  are  realistic  in  that  "critical" 
here  implies  maximum  or  minimum  timing  constraints.  In  addition,  a  negative  time 
value  would  be  meaningless  and  the  time  units  available  in  PSDL  (i.e.  millc-  or  micro¬ 
seconds)  provide  sufficient  time  divisions. 
c.  "Sort_Topological" 

After  the  "Pre_Process_File"  function  creates  its  output  files,  the  Static 
Scheduler's  next  major  function  is  performing  a  topological  sort  of  the  link,  statements 
contained  in  the  Links  file.  In  order  to  appreciate  the  complexity  of  this  topological 
sort,  Figure  11  on  page  34  illustrates  a  PSDL  linear  augmented  graph  and  its  corre¬ 
sponding  sorted  link  statements.  Lower  case  ciiaracters  identify  data  streams  which 
provide  data  value  communication  paths  between  two  operators.  The  upper  case  char¬ 
acters  identify  the  critical  operators.  An  operator  identifier  appearing  on  the  left  side 
of  the  arrow  represents  a  producer  of  data.  An  operator  identifier  appearing  on  the  right 
side  of  the  arrow  represents  a  consumer  (user)  of  data  values.  The  special  word  EX¬ 
TERNAL  identifies  a  situation  where  the  data  input.'output  arrives.exits  the  current 
level  of  the  system  under  consideration  depending  on  whether  EX  TERNAL  is  located 
on  the  left/right  of  the  link  statement.  The  numerical  value  on  the  right  side  of  the  colon 
records  the  MET  value  and  unit  of  measurement  lor  the  operator  identifier  on  the  left 
side  of  the  colon. 

All  link  statements  conform  to  this  same  format  regardless  of  the  level  of 
decomposition  under  consideration.  However,  as  these  lower  levels  are  encountered, 
each  single  statement  could  be  replaced  by  or  affect  two  or  more  statements.  As  an  ex¬ 
ample,  Figure  12  on  page  3.5  illustrates  the  decomposition  of  operator  13  from 
Figure  il  on  page  34.  A  comparison  of  the  two  figures  indicates  that  two  new  state¬ 
ments  were  added: 

•  bl*  .  131  :  5  ms  ~>  B2 

•  b2*  .  132  :  10  ms  ~>  B3 

and  two  statements  were  modified: 

•  b  .  A  :  10  ms  -->  13  is  now  b  .  A  :  10  ms  —  >  131 

•  c  .  B  :  20  ms  —  >  C  is  now  c  .  B3  :  5  ms  C. 


Tigure  11.  PSDL  Graph  and  Link  Statements 

All  of  the  link  statements  from  each  level  appear  sequentially  in  the  Links  file  as  they 
were  extracted  from  the  PSDL  prototype  program. 

The  requirement  for  a  topological  sort  implies  that  the  statements  being 
sorted  have  a  natural  continuity  and  connectedness.  These  properties  define  the  exe¬ 
cution  precedence  of  the  time  critical  operators  regardless  of  whether  the  graphs  are  li¬ 
near  or  acyclic.  With  a  linear  graph,  the  sort  establishes  a  start  point  by  locating  the 
statement  containing  the  EXTERNAL  keyword  in  the  left-hand  operator  position. 
Conversely,  the  end  point  is  established  by  locating  a  statement  containing  tiic  EX¬ 
TERNAL  keyword  in  the  right-hand  operator  position.  The  remaining  operators  arc 
ordered  by  locating  matches  between  the  right  and  left-hand  operators.  Sorting  an 
acyclic  digraph  differs  only  in  how  the  start  and  end  points  arc  established.  The  acyclic 
sort  establishes  a  start  point  by  locating  the  statement(s)  having  a  left-hand  operator 
with  no  matching  right-hand  operator.  The  end  point  is  established  by  locating  the 
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b.A  :  10  ms 

- - 

-->  B 1 

bl'.BI  :  5  ms 

~ >  B2 

b2*.B2  :  10  ms 

-->  B3 

c.B3  5m 

— >  C 

Figure  12.  Decomposition  of  Operator  B 

statement  having  a  right-hand  operator  with  no  matching  left-hand  operator.  An  aug¬ 
mented  acyclic  digraph  is  illustrated  in  Figure  13  on  page  36.  In  this  type  of  digraph, 
a  decision  to  choose  the  "a.A"  link  first  and  the  "d.A"  link  last  is  arbitrary.  The  output 
from  either  sort  is  a  precedence  list  of  critical  operators  stipulating  the  exact  order  in 
which  they  must  be  executed. 

As  conceptualized,  implementation  of  the  current  design  is  based  on  two 
assumptions.  First,  this  design  assumes  that  the  link  statements  are  formatted  correctly. 
Tins  assumption  is  realistic  here  and  especially  in  future  designs  when  the  L’l  contains 
a  syntax-directed  editor.  Second,  although  this  design  assumes  a  linear  graph,  the  sort 
procedure  will  accommodate  both  linear  graphs  and  acyclic  digraphs.  The  linear  sort 
will  produce  one  precedence  list  while  the  acyclic  sort  can  produce  two  or  more  preced¬ 
ence  lists. 
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Figure  13.  PSDL  Augmented  Acyclic  Digraph 


</.  "  Build _Hmnwnic_Blot:k  s " 

A  second  output  of  the  "I’re-Process_File"  function,  the  Operator  file,  is  the 
input  to  the  next  major  function  of  building  harmonic  blocks.  An  harmonic  block  as 
defined  in  this  thesis  is  a  set  of  periodic  operators  where  the  periods  of  all  its  component 
operators  are  exact  multiples  of  a  calculated  base  period  (Ref.  4:  p.  7J.  This 
implementation  design  treats  each  harmonic  block  as  an  independent  scheduling  prob¬ 
lem.  When  this  definition  is  applied  to  scheduling  hard  real-time  constraints,  the  design 
approach  requires  one  processor  for  each  harmonic  block.  This  approach  utilizes  the 
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capabilities  of  concurrency  and  multi-processing  which  are  normally  a  requirement  for 
complex,  hard  real-time  systems.  The  implementation  used  in  this  thesis  addresses  a 
single-processor  environment  only.  Therefore,  the  procedures  utilized  in  generating  the 
final  static  schedule  assume  that  only  one  harmonic  block  is  created.  The  following 
sections  describe  how  sporadic  operators  are  converted  to  their  periodic  equivalents, 
how  the  base  period  is  calculated  and  how  it  relates  to  the  harmonic  block,  and  finally, 
how  the  harmonic  blocks  are  created. 

The  Operator  file  generated  earlier  contains  all  the  critical  operators  with 
their  timing  constraints  that  were  extracted  from  the  PSDL  prototype  program.  How¬ 
ever,  this  file  can  initially  contain  both  periodic  and  sporadic  operators.  Periodic  oper¬ 
ators  are  triggered  for  execution  at  approximately  regular  intervals.  The  resultant 
triggering  interval,  or  period,  is  the  governing  factor  that  identifies  an  operator  as  peri¬ 
odic.  This  periodicity  helps  insure  that  execution  is  completed  between  the  beginning 
of  a  period  and  its  deadline,  which  defaults  to  the  end  of  the  period.  In  contrast,  spo¬ 
radic  operators  are  data-driven,  meaning  that  they  are  triggered  by  the  arrival  of  a  new 
data  value  or  set  of  values.  Attempts  to  create  a  static  schedule  with  sporadic  operators 
would  prove  difficult,  if  not  impossible,  especially  when  the  objective  of  a  static  schedule 
is  guaranteeing  execution  of  operators  in  a  predictable  manner.  For  this  reason,  spo¬ 
radic  operators  are  implemented  by  their  calculated  periodic  equivalent. 

The  first  preliminary  step  in  creating  a  static  schedule  uses  an  algorithm 
[Ref.  4:  p.  8[  which  calculates  the  periodic  equivalent  for  all  sporadic  operators.  Use 
of  this  algorithm  requires  that  all  sporadic  operators  (those  without  periods)  have  values 
for  MCP,  MRT,  and  MET.  If  any  of  these  values  arc  missing  they  must  be  calculated 
from  the  available  information.  The  MRT  value  was  computed  during  the 
"Validate_Data"  function.  This  implementation  assumes  that  MET  is  given  for  all  time 
critical  operators  and  that  either  a  period,  an  MCP,  or  both  arc  also  given  for  all  critical 
operators.  This  author  interprets  the  latter  as  indicating  that  an  operator  with  both 
values  defaults  to  a  periodic  operator.  The  following  relationships  between  these  values 
must  exit  to  calculate  a  valid  operator: 

1.  MET  <  MRT 

2.  MCP  <  MRT 

3.  MET  <  MCP. 

The  first  condition  insures  that  (  MRT  -  MET  )  produces  a  positive  value.  The  second 
condition  is  necessary,  but  it  is  not  sufficient  to  insure  a  valid  period.  This  condition 


guarantees  that  an  operator  can  lire  at  least  once  before  a  response  is  expected.  The  last 
condition  insures  that  the  period  calculated  will  conform  to  a  single-processor  environ¬ 
ment.  [Ref.  16;  p.  6]  The  periodic  equivalent  is  then  calculated  as 

P  =  minimum  (  MCP,  MRT  -  MET  ). 

The  value  of  P  must  be  greater  than  MET  in  order  for  the  operator  to  complete  exe¬ 
cution  within  the  calculated  period.  If  this  test  fails,  a  last  resort  is  setting  P  equal  to 
MCP  as  a  worst  case,  or  tightest,  scheduling  constraint. 

After  all  operators  are  in  periodic  form,  they  are  sorted  in  ascending  order 
based  on  the  period  values.  This  sort  assumes  that  all  units  of  time  measurement  were 
previously  converted  to  microseconds.  A  second  preliminary  step  to  creating  the  static 
schedule  uses  an  algorithm  which  calculates  the  base  block  and  its  period  for  the  sorted 
sequence  of  operators.  Within  this  thesis,  the  base  period  is  defined  as  the  greatest 
common  denominator  (GCD)  of  all  operators  in  one  sequence  (or  block)  that  will  be 
scheduled  together.  Two  algorithms  can  be  used  for  determining  the  GCD.  One  ad¬ 
dresses  a  single-processor  environment  only.  This  algorithm  divides  each  period  value 
in  the  sequence  by  the  smallest  period  value.  Whenever  a  remainder  occurs,  the  de¬ 
nominator  is  decreased  by  one  and  the  process  repeats  until  all  remainders  equal  zero. 
This  algorithm  results  in  one  sequence  of  periods  (the  base  block)  with  one  base  period 
(the  GCD). 

The  second  algorithm,  applicable  to  multi-processor  environments,  is  simi¬ 
lar  in  design  but  results  in  one  or  more  base  blocks,  each  having  a  unique  GCD  and  a 
unique  sequence  of  operators.  An  initial  pass  through  all  of  the  periods  results  in  two 
sequences,  only  one  of  which  is  a  final  base  block  with  a  GCD.  When  division  results 
in  a  zero  remainder,  the  period  is  placed  in  a  primary  sequence.  When  division  results 
in  a  non-zero  remainder,  the  period  is  placed  in  an  alternate  sequence.  Subsequent 
passes  only  use  the  most  recent  alternate  sequence.  This  process  is  continued  until  the 
alternate  sequence  equals  the  null  set.  T  his  implementation  uses  the  second  algorithm 
for  two  reasons.  First,  although  the  basic  designs  arc  similar,  the  implementation  is 
more  straightforward.  Second,  for  a  single-processor  environment,  the  second  pass  ver¬ 
ifies  that  all  periods  were  assigned  correctly  to  the  first  sequence  if  the  alternate  sequence 
equals  the  null  set. 


The  last  preliminary  step  to  create  the  static  schedule  uses  an  algorithm 
which  calculates  the  length  of  time  for  the  harmonic  block.  In  a  single-processor  envi¬ 
ronment,  the  operators  and  their  periods  used  to  create  the  base  block  are  the  same  as 
those  in  the  harmonic  block.  The  actual  harmonic  block  length  is  the  least  common 
multiple  (LCM)  of  all  the  operators'  periods  contained  in  the  block.  The  algorithm  first 
calculates  the  GCD  as  above  for  the  first  pair  of  periods  in  the  block.  The  LCM  is  then 
calculated  by  dividing  the  product  of  tliis  pair  by  the  GCD.  The  calculated  LCM  is 
paired  with  the  next  period  in  the  block,  after  which  the  GCD  and  LCM  are  again  cal¬ 
culated.  The  LCM  calculated  using  the  last  such  pair  is  the  LCM  lor  the  harmonic 
block.  Mathematically,  for  a  block  of  four  periods  the  algorithm  corresponds  to 

LENGTH  =  LCM  [  LCM  (  PeriodJ.  Period_4  )  J. 

The  harmonic  block  and  its  length  are  an  integral  part  of  creating  the  static  schedule. 
This  block  represents  an  empty  timeframe  within  which  the  operators  will  be  allocated 
time  slots  for  execution. 

e.  "Schedule_Operators" 

The  "Sort_Topological''  and  "Build_IIarmonic_Blocks"  functions  generated 
output,  files  Cor  rreeedence_Lists  and  Harmonic_Blocks,  respectively.  Both  of  these  files 
are  necessary  to  create  a  static  schedule  for  time  critical  operators.  The 
Precedcnce_Lists  file  contains  the  required  sequential  execution  order  for  all  time  critical 
operators.  The  I  Iarmonic_Blocks  file  contains  the  basic  timeframe  within  which  the 
critical  operators  are  allocated  non-overlapping  time  slots.  The  resulting  static  schedule 
is  a  linear  table  giving  the  exact  execution  start  time  for  each  critical  operator  and  the 
reserved  MET  within  which  each  operator  completes  it  execution. 

The  algorithm  used  in  this  implementation  is  a  two-step  process,  both  of 
which  use  the  operators'  periods  and  METs.  The  first  iterative  piocess  performs  two 
distinct  functions.  Initially,  it  allocates  an  execution  time  interval  for  each  operator 
[Ref.  10:  p.  126|  based  on 

INT  ERVAL  =  (  currcnt_timc,  current  time  +  MET  ). 

Next  the  process  creates  a  firing  interval  for  each  operator  during  which  the  second  it¬ 
erative  process  must  schedule  the  operator.  The  firing  interval  stipulates  the  lower  and 
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upper  bound  for  the  next  possible  start  time  lor  an  operator  based  on  its  period.  As  an 
example.  OP_2  in  Figure  14  on  page  41  is  scheduled  to  begin  execution  at  time  2  and 
to  complete  execution  by  time  3  based  on  its  MKT  of  I.  With  a  period  of  10,  OP_2  can 
not  fire  again  before  time  12,  the  lower  bound.  But  OP_2  must  fire  at  or  before  time  21. 
the  upper  bound,  in  order  to  guarantee  that  execution  is  completed  on  or  before  time 
22. 

The  second  process  has  three  distinct  functions.  Initially,  it  uses  the  lower 
bound  of  each  firing  interval  when  it  schedules  operators  during  subsequent  iterations. 
The  sequence  of  operators  is  allocated  time  slots  according  to  the  earliest,  lower  bound 
first.  For  the  example  in  the  previous  figure,  the  operators  are  scheduled  in  the  order  { 
OP_l,  OP_2,  OP_3  }  during  the  first  iteration  in  this  process.  Since  OP_4  has  a  period 
of  20  units  and  the  harmonic  block  length  is  also  20  units,  OP_4  is  scheduled  only  once 
in  each  harmonic  block.  Before  an  operator  is  allocated  a  time  slot,  this  process  verifies 
that  either: 

1.  (  current_tiine  +  MET  )  <  harmonic  block  length 

2.  (  current_time  +  MET  )  =  <  harmonic  block  length. 

The  second  condition  is  applicable  to  the  last  operator  scheduled  in  that  harmonic  block 
only.  Failure  to  meet  either  condition  results  in  an  infeasible  schedule.  This  situation 
raises  an  EXCEPTION  which  halts  execution  since  the  timing  constraints  of  that  oper¬ 
ator,  or  of  future  operators  in  the  next  iteration,  will  not  be  met. 

This  process  also  calculates  new  firing  intervals  for  each  operator  scheduled. 
As  an  example,  Figure  15  on  page  42  shows  the  static  schedule  and  two  harmonic 
blocks  after  three  iterations  of  this  process.  This  example  illustrates  the  importance  of 
calculating  an  accurate  harmonic  block.  Once  all  operators  are  correctly  scheduled 
within  an  entire  harmonic  block,  all  subsequent  harmonic  blocks  are  copies  of  tire  first 
—  a  static  schedule. 

2.  Static  Scheduler  Implementation 

This  Chapter  described  the  conceptualized  design  utilized  to  implement  the 
Static  Scheduler.  The  primary  objective  was  providing  background  knowledge  of  the 
overall  design  using  the  1st  level  DFD.  Additional  details  were  included  to  enhance  the 
reader's  understanding  of  the  implementation  guidelines  presented  in  Chapter  IV  using 
tiie  Ada®  programming  language  and  the  lower  level  DTDs  in  Appendix  C. 
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6lven  the  following  Information: 

PRECEDENCE— LISTS  {  OP-1 , OP-2.  GP_3.  0P_4  } 
HARHOmC_BtOOLJL£IIGTH  »  20 


aKBAIMUB,  EEL  PgRWP 

OP-1  2  10 

OP-2  1  10 

OP-3  3  20 

OP-4  1  10 


STATIC  SCHEDULE: 


START 

END 

FIR  mo 

OPERATOR-ID 

-DEL 

0 

UBL 

2 

INTERVAL 

0P_1 

00,18) 

OP-2 

2 

3 

(12,21) 

0P_3 

3 

6 

(23,40) 

OP-4 

6 

7 

(16,23) 

HARMONIC  BLOCK: 
12  3  4 


0  S  10  13 


Figure  14.  Static  Schedule  after  First  Process 
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Figure  15.  Static  Schedule  for  2  Harmonic  Clocks 


IV.  STATIC  SCHEDULER  IMPLEMENTATION 

3 

The  inlormation  outlined  in  Chapter  III  described  the  importance  of  the  Static  j 

Scheduler  to  the  computer-aided  rapid  prototyping  environment  and  laid  the  ground-  > 

work,  for  designing  the  implementation  guidelines.  Utilizing  the  algorithms  described  ] 

verbally  in  Chapter  III  and  the  DFDs  from  Appendix  C,  this  Chapter  describes  the 
analysis,  alternatives  and  decisions  required  to  produce  the  Ada®  pseudocode  in  Ap-  I 

r 

pendix  E.  \ 


A.  OVERALL  PROGRAM  STRUCTURE 

As  graphically  shown  in  the  1st  Level  DFD  in  Appendix  C  (Figure  IS  on  page  67). 
the  Static  Scheduler  was  conceptualized  as  live  primary  functional  programming  units 
or  bubbles.  Each  of  the  live  bubbles  was  decomposed  into  one  or  more  subsections 
which  perform  individual,  specific  functions.  Together,  these  subsections,  or  lower  lev¬ 
els,  achieve  the  stated  goal  of  the  primary  bubble.  These  subsections  are  graphically 
described  in  increasingly  more  detail  in  the  2nd,  3rd  and  4th  level  DFDs  also  found  in 
Appendix  C. 

Two  additional  primary  programming  units  were  identified  during  the  initial  analysis 
period.  These  include  one  programming  unit  comprised  of  all  common  files  and  a  sec¬ 
ond,  the  main  driver  program.  Initially  the  1st  Level  DFD  described  the  data  How  be¬ 
tween  the  bubbles,  while  further  analysis  indicated  that  all  the  bubbles  utilized  attributes 
from  four  primary  and  permanent  files.  Combining  all  four  of  these  files  in  one  pro¬ 
gramming  unit,  an  Ada®  library  package,  allows  global  access  to  all  data  attributes  by 
any  other  bubble.  Second,  when  using  a  structured  programming  approach,  common 
practice  requires  a  main  driver  program  which  provides  sequential  control  of  program 
execution.  The  driver  program,  implemented  as  a  procedure  in  this  application,  contains 
a  sequence  of  call  statements  which  temporarily  pass  execution  control  to  a  particular 
programming  unit.  Upon  execution  completion  by  the  called  unit,  program  control  le- 
turris  to  the  driver  program  at  the  point  immediately  below  the  previously  called  state¬ 
ment.  In  this  way,  the  driver  program  provides  a  thread  of  control  through  all  of  the 
program  modules. 

I.  Naming  Conventions 

Before  relating  a  specific  lower  level  DFD  to  its  implementation  in  the  Ada® 
pseudocode,  the  reader  requires  one  caveat.  The  1st  and  2nd  level  DFDs  were  adapted 
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for  this  thesis  fiom  a  separate  research  dibit  while  the  3id  and  4th  level  Df'Ds  were 
designed  during  the  initial  stage  of  this  research.  Therefore,  the  names  used  to  identify 
bubbles  in  the  DFDs  will  not  always  precisely  match  the  names  associated  with  their 
pseudocode  implementation.  Sufficient  similarity  does  remain  which  should  preclude 
unnecessary  confusion.  In  addition,  there  are  cases  where  a  lower  level  bubble  has  no 
unique  program  unit.  These  situations  occurred  when  the  author  determined  that  the 
function  described  by  the  bubble  represented  a  single  operation  and  did  not  warrant  a 
stand-alone  program  unit. 

2.  Implementation  Approach 

The  remainder  of  this  Chapter  will  outline  the  transition  from  a  conceptualized 
idea  to  the  pseudocode  implementation  for  the  Static  Scheduler.  Each  presentation  that 
follows  begins  with  an  analysis  of  the  program  module  and  the  end  result  that  must  be 
realized.  Second,  any  alternative  approaches  that  will  achieve  the  same,  or  similar,  ac¬ 
ceptable  result  are  identified.  Finally,  if  alternative  solutions  were  identified,  the  pres¬ 
entation  concludes  with  a  description  of  the  alternative  chosen  for  this  implementation 
guideline. 

B.  PROGRAM  EXCEPTION  HANDLING 

Run-time  errors  generally  occur  during  program  execution  due  to  hardware  failure, 
software  inconsistencies  or  erroneous  interactive  data  input.  An  error  is  more  precisely 
defined  as  an  exception  to  the  normal  or  anticipated  behavior  of  a  system.  With  pro¬ 
duction  software,  these  exception  situations  indicate  "bugs"  which  require  either  imme¬ 
diate  or  eventual  modification  depending  on  their  impact  to  the  system  overall.  With 
computer-aided  rapid  prototyping,  however,  an  exception  situation  should  alert  the 
software  designer  and  the  user  to  inconsistencies  in  the  design  or  parameters  used  to 
develop  the  prototype.  In  hard  real-time  or  embedded  systems,  exception  handling  in¬ 
creases  the  reliability  of  critical  program  segments  and  can  aid  in  graceful  degradation 
of  the  system  should  exceptions  occur. 

1.  Ada  Exception  Handling 

The  Ada®  programming  language  includes  both  predefined  and  user-defined 
exceptions.  The  sets  of  pre-defmed  exceptions  address  conventional  errors  usually  han¬ 
dled  by  the  underlying  operating  system,  such  as  DI:VTCE_[;RROR.  In  contrast,  user- 
defined  exceptions  can  address  specific  input  parameters  or  calculated  values  that  are 
outside  the  expected  or  anticipated  system  constraints. 
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A  standard  rule  for  designing  exception  handlers  stresses  that  exceptions  should 
be  identified  and  resolved  at  the  lowest  possible  level  in  the  program  [Ref.  1:  p.  3 If]. 
Within  Ada®,  after  an  exception  is  resolved,  execution  control  returns  to  the  end  of  the 
particular  programming  unit  where  the  exception  was  handled.  Thus,  if  an  exception  is 
handled  within  a  local  procedure  (subroutine),  the  driver  program  is  unaware  of  its  oc¬ 
currence.  In  a  computer-aided  prototyping  environment,  this  also  implies  that  the  de¬ 
signer  and  user  lose  "real-time"  ability  to  evaluate  the  impact  of  the  exception. 

2.  Static  Scheduler  Exception  Handling 

An  alternative  solution,  utilized  for  this  implementation,  raises  the  exception  in 
the  local  program  unit  but  passes  exception  handling  to  the  driver  program.  The  ex¬ 
ceptions  raised  in  the  Static  Scheduler,  as  shown  in  Figure  16  on  page  46.  concern  the 
validity  of  the  timing  constraints  identified  by  the  user.  Exceptions  1  through  6  indicate 
that  either  required  constraints  are  missing  or  they  are  logically  inconsistent.  As  an  ex¬ 
ample.  the  third  exception  would  be  raised  when  MET  >  MRT,  which  indicates  a  neg¬ 
ative  period  of  tune.  Exceptions  7,  8  and  9  indicate  that,  although  a  schedule  may  be 
possible,  there  is  no  guarantee  that  it  will  execute  within  the  required  timing  constraints. 
Exceptions  10,  11  and  12  indicate  that,  with  the  given  timing  constraints,  no  feasible 
schedule  exits  which  meets  the  requirements  of  the  envisioned  system. 

Depending  on  the  system  application  and  the  user,  exception  handling  could 
include  built-in  contingencies  to  modify  the  constraints  rather  than  suspend  execution 
of  the  prototype.  However,  this  approach  would  increase  the  complexity  of  the  proto¬ 
type  and  the  performance  statistics  reported  to  the  designer  and  user. 

C.  PACKAGE  PRESENTATIONS 

The  Static  Scheduler,  as  implemented  in  this  thesis,  contains  six  package  program¬ 
ming  units.  Five  packages  represent  the  five  primary  functional  groupings  with  one  ad¬ 
ditional  package  containing  only  permanent  or  global  file  information.  A  package  is  a 
collection  oflogically  related,  computational  resources  which  support  a  structured,  mo¬ 
dular  design  and  abstract  data  or  type  representations,  d  ims,  the  Ada®  package  con¬ 
struct  provides  the  required  mixture  of  accessibility  and  information  hiding  for  this 
application.  By  design,  the  package  declaration  section  contains  sufficient  visible  infor¬ 
mation  which  facilities  information  exchange  between  programming  units.  At  the  same 
time,  a  package  declaration  can  contain  invisible  ( private)  sections  which  contain  struc¬ 
tural  level  details  that  arc  irrelevant  to  the  outside  users.  [Ref.  1:  pp,  218-219]  How¬ 
ever,  in  this  application,  private  types  were  not  utilized  in  order  that  the  reader  could 
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PACKAGE  NAME 


EXCEPTION  NAME 


1. 

FILE_PROCESSOR 

ME'f_EQL'ALS_PER10D 

2. 

FILE_PROCESSOR 

M  ET_N  OT_  L  E  S  S_TI  I  AN_M  RT 

3. 

TOPOLOGICAL_SORTER 

NO_I N IT  I A L_L I N K_OP 

4. 

TOPOLOGICALSORTER 

NO_M  A  I'd  lES_r  OL  N  D 

5. 

1 1 A  R.V1  ON  1  C_B  LOC  K_B  U I LD  E  R 

CONSTRAINTS_IN  VALID 

6. 

ITARMONTCBLOCKBUILDER 

NO_BASE_BLOCK 

7. 

OPERATOR_SCIIEDULER 

FA  I  L_1 1 A  L  1:_P  E  R 1 0  D 

8. 

0  P  E  RAT  0  R_SC1 1 E  D  U  L  E  R 

B  A  D_TOT  A  L_T  I M  E 

9. 

OPE  RATO R_SC II E D U L E R 

RAT  1 0_T  00_B  I G 

10. 

OPE  RATO  R_SCIIEDLLER 

OVERJTME 

11. 

OPE  RATO  R_S  C  H  E  D  L  L  E  R 

INVALID_SCIIEDULE 

12. 

OPERATOR_SCHEDULER 

SCHEDULE_ERROR 

Figure  16.  Static  Scheduler  Exceptions 


more  easily  follow  program  development.  The  following  sections  describe  each  of  these 
packages  and  outline  specific  implementation  considerations. 

1.  "Files"  Package 

The  Files  package  groups  together  the  four  permanent  files  containing  critical 
operators  and  their  timing  constraints.  This  structure  provides  a  global  database  for  use 
by  all  of  the  other  packages  as  required.  The  Links  and  the  Operators  files  arc  created 
from  the  information  identified  and  retrieved  from  the  PSDL  prototype  source  program 
during  the  Separatc_Data  procedure  within  the  File  Processor  package.  The 
Prcccdencc_List  is  created  by  a  precedence  level  sort  routine  during  the  Creaic_l.ists  and 
Sort_Remuining_Operators  procedures  within  the  TopologicaljSortcr  package.  The 
Schedulc_Inputs  file  is  created  by  two  function  programming  units,  Caie_l.ower  and 
Calc_Uppcr.  T  hese  two  sub-units  arc  called  by  the  (  'rcate  lnterval  procedure  within  the 
Operator_Seheduler  package.  The  Files  package  represents  an  Ada®  library  package 
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which  is  accessible  to  all  other  programming  units  by  specifying  the  "with  files"  state¬ 
ment  prior  to  the  package  declaration. 

Several  alternative  approaches  were  considered  for  structuring  this  database  of 
timing  constraints.  One-dimensional  arrays  initially  appeared  most  appropriate  with 
their  built-in  indexing  structure.  However,  the  array  construct  requires  a  priori  know¬ 
ledge  of  the  a. ray  size  before  compilation  time.  The  second  approach  considered,  linked 
lists,  would  eliminate  the  need  to  include  repetitive  entries  between  files.  In  this  appli¬ 
cation,  the  operator  identifier  must  be  included  in  each  file.  But  this  approach  would 
also  conceal  the  unique  character  or  use  for  each  file.  Tire  author  believed  that  the  re¬ 
cord  format  utilized  in  this  implementation  was  the  most  straightforward  description  of 
the  individual  files  and  their  attributes. 

2.  'TSDL_  Reader"  Package 

The  package  PSDL_lleader  implements  a  2nd  level  DI  D  from  Appendix  C 
(figure  19  on  page  6S).  Implementation  assumptions  for  this  application  were  outlined 
in  Chapter  III,  Section  B.l.a.  This  package  represents  the  single  most  important  aspect 
of  the  Static  Scheduler.  The  procedure  Invoke_AG_Processor  initiates  the  Kodiyak  AG 
processor  that  was  developed  in  conjunction  with  this  Static  Scheduler  implementation. 
The  procedure  Read_thc_File  uses  the  output  of  the  Kodiyak  AG  processor  as  the 
source  for  all  ol'  the  operators  and  the  timing  constraints  needed  to  create  tire  static 
schedule. 

it.  Kodiyak  AG  Processor 

Appendix  D  contains  a  complete  program  listing  of  the  Kodiyak  AG  pro¬ 
cessor  as  it  was  tailored  for  this  application.  The  attribute  grammar  section  of  the  pro¬ 
cessor  contains  the  grammar  symbols,  along  with  their  syntax  and  attribute  definition 
equations,  which  identify  the  symbols  within  the  PSDL  prototype  program  that  the 
Static  Scheduler  requires.  Those  required  symbols  are  the  operator  identifiers  and  their 
critical  timing  constraints  (operator,  maximum  execution  time,  maximum  response  time, 
minimum  calling  period,  time,  unit,  links,  period,  and  finish). 

Theoretically,  the  Kodiyak  AG  translator  generator  is  an  easy-to-use,  eifi- 
cieut  tool  for  creating  specialized  processors.  However,  experience  showed  that,  in  order 
to  identify  the  nine  required  symbols,  at  least  30  attribute  definition  equations  required 
modification.  1  he  author  determined  that  the  difficulties  encountered  with  creating  the 
AG  processor  centered  around  two  significant  areas,  f  irst,  the  Kodiyak  AG  process*. : 
is  based  on  a  tree  architecture  which  "grows"  or  develops  as  the  grammar  symbols  are 


interprctted.  Problems  could  possibly  arise  when  only  a  small  subset  of  the  symbols  arc 
required,  leaving  discontinuities  within  the  branching  of  the  tiee.  Second,  proficiency  in 
using  the  Kodiyak  AG  software  tool  requires  an  extensive  learning  curve.  Minimal  do¬ 
cumentation  requires  verbal  "pass  down"  of  lessons  learned  or  repetitive  trial  and  error 
to  eliminate  reduction  errors.  In  addition,  error  reporting  at  compilation  time  is  not 
sufficient  for  a  student  new  to  the  area  oflanguage  translatois. 

3.  "File_ Processor"  Package 

The  package  File_Processor  implements  a  2nd  level  DFD  from  Appendix  C 
(Figure  20  on  page  69).  Implementation  assumptions  for  this  application  were  outlined 
in  Chapter  III,  Section  B.  l.b.  This  package  contains  a  sort  routine  and  a  data  input 
validation  phase.  The  Separate_Data  (sort)  procedure  uses  an  input  file,  AG_OutfiIe. 
created  >■>’•  the  PSDL_Reader  package.  This  procedure  creates  three  tiles.  One  of  the 
files.  Non-Crits,  is  used  by  the  Static  Scheduler  to  schedule  non-time  critical  operatois 
and  contains  operator  identifiers  retrieved  from  the  AG  output  that  do  not  include  an 
MET  value,  a  requirement  lor  critical  operators.  The  two  files  created  for  the  Static 
Scheduler  are  the  Links  and  the  Operators  files.  The  components  of  the  Links  file  are 
identified  within  the  AG_Outfile  by  the  keywords  "graph"  and  "links".  The  components 
of  the  Operators  file  are  identified  by  the  keywords  "operators",  "operator_spcc", 
"max_exec_time",  "max_resp_time",  "min_period"  "time",  "unit",  "period",  and  "finish". 

A  fourth  set  of  retrieved  symbols  are  dumped  to  a  temporary  file,  Trash_Filc. 
These  symbols  arise  due  to  a  data  type  to  operator  interconnection  inherent  in  the  PSDL 
language.  The  cross  connection  stems  from  the  "type_impl"  (data  type  implementation) 
and  the  "type_spec"  (data  type  specification)  constructs  in  PSDL.  The  PSDL  and  AG 
definition  equations  for  these  symbols  include  operators  that  are  utilized  in  the  data  type 
implementations.  The  author  did  not  associate  these  equations  with  the  critical  operator 
specifications  and  implementations  required  by  the  Static  Scheduler. 

The  Validate_Data  procedure  uses  attributes  from  the  Operators  file  to  perform 
basic  validity  checks  on  the  timing  constraints.  As  described  in  Chapter  III,  certain  re¬ 
lationships  arc  required  between  timing  constraints  to  insure,  with  some  degree  of  reli¬ 
ability,  that  a  static  schedule  is  feasible.  Therefore,  timing  constraint  relationships  ate 
validated  as  early  as  possible  in  this  implementation.  An  exception  is  raised  when  any 
constraint  fails  a  validity  test.  This  prompt  feedback  allows  the  designer  and  the  user 
to  modify  constraints,  when  necessary,  eaily  in  the  prototype  construction  and  demon¬ 


stration. 


4.  "TopologiealjSorter"  Package 

The  package  Topoiogical_Sorter  implements  three  lower  level  DFDs  which  ap¬ 
pear  in  Appendix  C  (Figure  21  on  page  69  through  Figure  23  on  page  70).  Implemen¬ 
tation  assumptions  for  this  application  were  outlined  in  Chapter  III,  Section  B.l.c.  This 
package  utilizes  two  procedures  and  the  Links  file  to  initiate  and  build  the 
Precedence_List  file. 

The  initial  procedure  Create_Lists  must  identify  the  starting  point  for  the  topo¬ 
logical  sort.  The  procedure  uses  a  pair  of  nested  loops  to  compare  the  first  operator 
identifier[i]  on  the  left  of  the  arrow  with  each  and  every  operator  identifier]]]  on  the  right 
of  the  arrow.  The  operator  identifier^]  with  no  matching  identifier]]]  is  the  starting  point. 
Execution  control  passes  to  the  next  procedure  after  the  identifiers  ]t]  and  [j]  are  posi¬ 
tioned  in  the  Precedcnce_List  file. 

The  remaining  link  statements  are  sorted  within  the  Sort_Rcmaining_Operaiors 
procedure.  This  topological  sort  is  similar  to  the  operation  in  the  previous  procedure, 
but  reverses  the  logic.  In  this  sort,  precedence  relationships  among  operators  arc  eval¬ 
uated  by  comparing  the  first  operator]]]  on  the  right  of  the  arrow  with  the  second 
operator[i+  1]  on  the  left  of  the  arrow.  When  a  match  is  found,  operator[i+  I]  and  its 
corresponding  operator[j+  1]  are  placed  in  the  second  positions  of  the  Preccdence_l.ist. 
This  operation  continues  until  no  match  is  found,  indicating  the  end  of  the  Links  file. 
1  he  resulting  Precedence_List  is  used  as  input  to  the  Operator_ScheduIer  package. 

5.  "Build_Harmonic_Blocks"  Package 

The  package  Build_Harmonic_Blocks  implements  ten  lower  level  DFDs  from 
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Appendix  C  (Figure  24  on  page  71  through  Figure  33  on  page  75).  Implementation 
assumptions  for  this  application  were  outlined  in  Chapter  III,  Section  B.l.d.  This 
package  contains  four  major  procedures  which  create  an  harmonic  block  template  that 
is  tailored  to  the  critical  operators  and  their  firing  intervals. 

The  initial  procedure  Calc_Periodic_Fquivalents  contains  three  sub-procedures 
which  perform  specialized  operations.  The  procedure  Locatc_Sporadic_Operators  first 
identifies  critical  operators  that  fire  sporadically,  indicated  by  the  presence  of  an  MCI’ 
value  for  that  operator.  Second,  this  procedure  verifies  that  the  operator  recoid  contains 
an  MRT  value.  If  not  present,  the  procedure  creates  the  value  from  the  given  con¬ 
straints  as  cither  (  MRT  WITHIN  )  or  as  (  MRf  :=  MET  ).  The  second  major 
procedure  Verify_l  verifies  the  relationships  between  the  timing  constraint  values  that 
are  needed  to  calculate  the  equivalent  operator  period.  These  constraints  include  the 
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MCI’,  MRT  and  MET  values  lor  each  sporadic  operator.  Exceptions  are  raised  and 
execution  is  suspended  if  the  required  relationships  are  not  met.  These  exceptions  indi¬ 
cate  that  a  valid  static  schedule  is  not  feasible  with  the  given  timing  constraints.  The  last 
procedure  Period_Algo  calculates  the  equivalent  period  value  for  each  sporadic  operator. 
The  new  period  equals  the  smaller  value  of  either  MCP  or  (  MRT  -  MET  ). 

The  second  major  procedure  Sort_by_Pcriod  performs  an  ascending  order  sort 
based  on  the  operators'  periods.  The  third  major  procedure  Find_Base_Bloek  uses  this 
sorted  operator  sequence  to  verify  the  compatibility  of  the  operators.  In  order  to  create 
a  valid  static  schedule,  the  operators'  periods  must  be  multiples  of  a  common  divisor 
(GCD).  A  modulus  (mod)  division  function  embedded  within  nested  loops  calculates  the 
GCD  for  the  sequence  of  operator  periods.  For  a  single  processor  system,  a  single  GCD 
for  all  of  the  operators'  perioUo  verifies  that  a  valid  static  schedule  exists  for  the  given 
constraints. 

The  final  major  procedure  Find_Block_Length  calculates  the  actual  length  of 
the  harmonic  block  template.  This  procedure  uses  two  functions,  Find_GCD  and 
Find_LCM,  that  are  embedded  within  an  outer  loop.  This  process  continues  through 
the  sequence  of  all  operator  periods  until  a  final  LCM  is  calculated.  The  final  LCM 
equals  the  length  of  the  harmonic  block  within  which  the  critical  operators  will  be 
scheduled. 

6.  "Operator_Scheduler"  Package 

The  package  Operator_Schedulcr  implements  ten  lower  level  DFSs  from  Ap¬ 
pendix  C  (Figure  34  on  page  76  through  Figure  43  on  page  80).  Implementation  as¬ 
sumptions  for  this  application  were  outlined  in  Chapter  III,  Section  B.l.c.  This  package 
contains  four  major  procedures.  Th«.»e  procedures  verify  the  initial  feasibility  of  the 
harmonic  block's  accurate  execution,  schedule  the  operators  within  the  harmonic  block, 
and  finally  create  the  static  schedule  that  the  Dynamic  Scheduler  executes  at  prototype 
runtime. 

The  initial  procedure  Test  Data  utilizes  embedded  procedures  which  determine 
the  overall  feasibility  of  the  final  static  schedule  to  execute  within  the  timing  constraints. 
The  assumptions  behind  these  validity  tests  were  outlined  in  Chapter  III.  Each  proce¬ 
dure  raises  an  exception  if  the  static  schedule  inputs  fail  the  indicated  validity  test.  The 
procedure  Calc_Total_Timc  indicates  that  the  schedule  will  fail  at  execution  since  the 
number  of  operations  times  their  METs  is  greater  than  the  harmonic  block  length.  The 


procedures  Calc_Ualf_reriods  and  Calc_Ratio_Surn  indicate,  with  a  high  degree  of 
probability,  that  the  schedule  will  fail  during  execution. 

The  next  two  procedures,  Schcdule_Initial_Set  and  Schedule_Rest_ol_LSlock, 
utilize  the  Precedence_List  and  the  operators'  MET  values  to  create  a  firing  interval  for 
each  operator.  The  firing  interval  contains  the  start  time  and  worst  case  stop  time,  based 
on  MET,  for  each  operator.  The  stop  time  of  operator(i|,  together  with  the  period  of 
operator[i+  lj,  determine  the  start  time  for  operator[i+  1).  Although  initially  conceived 
as  a  single  procedure,  analysis  indicated  a  difference  in  scheduling  logic  between  the  first 
and  subsequent  passes  through  the  Prccedence_List.  During  the  second  and  future 
passes  the  operators'  execution  order  may  vary  from  the  Precedence_List  based  on  each 
operators'  period.  The  final  output  of  these  two  major  procedures  is  the 
Schedule_Inputs  tile  which  contains  a  pre-allocated  tiling  interval  (slot)  within  the  har¬ 
monic  block  for  each  time  critical  operator. 

The  final  procedure  Create_Static_$chedule  utilizes  the  Schcdule_Inputs  file  to 
create  the  static  schedule  used  by  the  Dynamic  Scheduler  at  run-time.  As  conceived  by 
the  author,  the  static  schedule  is  implemented  as  an  Ada®  package  containing  a  task 
programming  unit.  The  task,  in  turn,  contains  the  Ada®  rendezvous  statements  ENTRY 
and  ACCEPT.-  The  ENTRY  statements  call  either  the  next  scheduled  operator  or  the 
Dynamic  Scheduler.  The  Dynamic  Scheduler  is  called  when  either  a  non-allocated  time 
slot  is  reached  or  when  a  critical  operator  completes  execution  prior  to  its  scheduled  stop 


D.  RUNTIME  STATIC  SCHEDULE 


The  final  output  of  the  Static_Scheduler  program,  the  Static_Schcdule  file,  provides 
the  input  for  the  CLE.  The  CLE  compiles  the  Static  Scheduler  s  output  and  produces 
an  executable  Ada®  program.  An  example  of  the  compiled  program  is  shown  in 
Figure  17  on  page  52.  This  program,  together  with  the  executable  program  from  the 
ESS  Translator,  provide  the  executable  prototype  program  for  the  envisioned  system. 
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package  TIIE_STATIC_SCHEDULE  is 
task  SEQUENCE_OF_CALLS  is 

entry  EACH_OPERATOR.  OPERATOR[i]  (THE_START[i]  :  in  out  INTEGER; 

THE_STOP[iJ  :  in  out  INTEGER); 
entry  DYNAMIC  (THE  STOF[i]  :  m  out  INTEGER; 

TIIE_START[i+l]  :  in  out  INTEGER); 
end  SEQUENCE_OF  CALLS; 
end  THE_STATIC_SCUEDUL£; 

with  CALENDAR; 

package  body  THE_STATIC_SCHEDULE  is 
begin 

task  body  SEQUENCE_OF_CALLS  is 
begin 
loop 

procedure  THE_0PERAT0R[ i]  is 
begin 

accept  EACH_OPERATOR.  OPERATOR[i](THE_STARTri]  :  in  out  INTEGER; 

THE_STOP[i]  :  in  out  INTEGER); 

select 

when  CLOCK.  VALUE  <  TiiE_STOP[iJ  then 
entry  DYNAMIC 
or 

when  CLOCK.  VALUE  =  THE_STOP[i]  then 
entry  EACH_OPERATOR  (  OPERATOR[i]  ) 

else 

exception 

when  others  => 

raise  RUNTIME_MET_FAI LURE 
end  THE.OPERATOR; 
end  loop; 

end  SEQUENCE_OF_CALLS; 
end  TIIE_STATIC_SCHEDULE; 


Figure  17.  Ada®  Pseudocode  for  the  Statin  Schedule 


V.  TELECOMMUNICATIONS  APPLICATION 


The  utilization  of  digital  computers  in  telecommunications  systems,  in  general, 
greatly  increases  the  DOD's  and  DON'S  ability  to  meet  the  growing  needs  of  users,  both 
ashore  and  afloat.  The  advent  of  embedded  computer  systems  which  preform  automated 
circuit  switching,  whether  at  a  station's  technical  control  facility  or  within  the  satellite 
itself,  will  again  increase  the  service  department's  ability  to  expand  or  add  new  telecom¬ 
munications  capabilities.  The  growth  of  and  demand  for  communications  services  would 
benefit  from  the  development  of  dynamic  circuit  or  channel  assignment  systems.  These 
systems  provide  improved  allocation  of  scarce  satellite  and  radio  frequency  spectrum 
resources.  Computer-aided  rapid  prototyping,  and  specifically  the  CAPS,  will  assist  in 
the  design  and  development  of  these  complex  telecommunications  systems. 

A  Satellite-Switched  Time  Division  Multiple  Access  (SS/TDMA)  system  is  a  specific 
example  of  a  telecommunications  system  whose  development  wmuld  benefit  from  the  use 
of  CAPS.  In  this  system,  communications  between  earth  stations  in  different  geographic 
areas  is  achieved  when  the  satellite  switches  (changes)  transmission  time  slots  from  one 
beam  to  another.  Only  one  station  from  each  individually  covered  area  can  transmit  to 
the  satellite  at  the  same  time.  If  N  areas  are  served,  then  the  satellite  switch  is  config¬ 
ured  to  handle  N!  modes  for  complete  connectivity  among  all  of  the  stations.  A  mode 
represents  a  defined  uplink-downlink  connection  from  each  statiun  to  every  other  sta¬ 
tion.  [Ref.  17:  pp.  309-311]  The  number  of  possible  modes  quickly  becomes  unman¬ 
ageable  without  automated  switching  systems.  The  complexity  and  precision  required 
for  designing  and  developing  such  a  system  can  be  represented  by  the  PSDL  computa¬ 
tional  model  used  in  the  CAPS. 

The  CAPS  described  in  this  thesis  provides  a  development  tool  which  is  easily 
adapted  to  modeling  real-time  or  embedded  switching  systems.  The  PSDL  computa¬ 
tional  model  (see  Chapter  II),  based  on  data  flow  through  a  system,  represents  an  ab¬ 
stract  view  of  both  the  hardware  and  software  of  these  complex  systems.  As  adapted  lor 
the  SS/TDMA  system,  the  computational  model  represents 


where: 


•  V  =  a  set  of  operators  (signal  processing  equipment) 

•  E  =  a  set  of  data  streams  (up  and  downlink  beams) 

•  T(v)  =  MET  for  each  operator  (v) 

•  C(v)  =  a  set  of  control  constraints  for  each  operator  (environmental  factors  and 
mode  configurations). 

These  MET  timing  and  control  constraints  are  declarations  about  the  system  itself  and 
the  environment  in  which  it  must  function.  This  is  in  contrast  to  instructions  within  the 
applications  software. 

The  communications  switching  system  aboard  the  satellite  receives  a  signal  via  a 
channel  on  the  uplink  beam.  The  system  then  processes  the  signal  in  some  manner  de¬ 
pending  on  the  application.  An  MET  associated  with  tins  process  insures  proper  exe¬ 
cution  of  the  TDMA  function  and  of  the  system  as  a  whole.  Control  constraints  for  this 
system  would  include,  for  example,  the  mode  configuration  routing  tables,  data  error  and 
flow  control,  and  system  load  capacity.  Once  the  switching  process  is  complete,  the 
system  transmits  the  signal  on  the  appropriate  downlink  beam.  When  the  above  infor¬ 
mation  is  applied  to  the  CAPS  and  the  prototype  is  executed,  the  resultant  demon¬ 
strations  of  the  prototype  can  be  used  to  validate  the  design  specifications  for  the 
receive,  process  and  transmit  functions  of  the  envisioned  SS.  TD.MA  system. 

As  users  of  military  telecommunications  systems  become  accustomed  to  high-speed, 
reliable  and  dynamic  communications,  applications  for  hard  real-time  or  embedded  sys¬ 
tems  will  increase.  These  systems,  especially  switching  systems,  arc  characterised  by 
multiplicity  and  concurrency  of  otherwise  simple,  interacting  functions.  The  conven¬ 
tional  approach  to  software  life  cycle  development  is  quickly  becoming  inadcaquatc  or 
obsolete  for  the  strenuous  demands  of  designing  and  developing  these  complex  systems. 
Abstract  modeling  of  telecommunications  systems  reduces  the  probability  of  develop¬ 
ment  failure  by  identifying  areas  with  the  highest  risk.  Design  cllons  arc  then  concen¬ 
trated  on  reducing  those  risks  by  demonstrations  of  the  prototype  early  in  the  design 
stages.  The  CAPS  tool  will  assist  procurement  and  development  agencies  in  meeting  the 
telecommunications  needs  of  the  future. 
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V!.  CONCLUSION 


The  goals  of  this  pioneering  effort  were  to  demonstrate  the  feasibility  of  imple¬ 
menting  a  Static  Scheduler  for  the  CAPS  and  to  provide  guidelines  for  its  implementa¬ 
tion.  This  thesis  outlines  the  tools  and  algorithms  that  are  required,  at  a  minimum,  to 
implement  the  Static  Scheduler  and  to  integrate  it  within  the  Execution  Support  System. 
This  study  accomplished  these  goals  while  identifying  specific  areas  of  concern  for  future 
research. 

The  Kodiyak  AG  translator  generator  is  an  effective  and  efficient  tool  for  processing 
a  PSDL  prototype  source  program.  An  AG  processor  designed  specifically  and  precisely 
for  the  Static  Scheduler  is  fundamental  to  the  successful  scheduling  of  time  critical  op¬ 
erators.  Misrepresentation  of  or  failure  to  identify  operators  and  their  timing  constraints 
negates  the  benefits  of  the  best  designed  scheduling  algorithms.  Lack  of  user  friendly 
error  messages  and  basic  manuals  causes  an  extensive  learning  period  using  trial  and 
error  or  verbal  "pass  down". 

The  Ada®  programming  language  provides  the  necessary  constructs  and  enforces  a 
modularized,  self-documenting  design,  both  of  which  enhance  the  feasibility  of  imple¬ 
menting  the  Static  Scheduler.  Ada®  user-defined  file  and  data  types  allow  precise  dec¬ 
laration  (definition)  of  critical  operators'  attributes  (timing  constraints).  Ada® 
rendezvous  operations  using  ENTRY  and  ACCEPT  statements  provide  a  means  to  es¬ 
tablish  and  enforce  execution  precedence  among  critical  operators.  Rendezvous  oper¬ 
ations  provide  the  backbone  of  the  runtime  static  schedule  created  by  the  Static 
Scheduler.  Formal  demonstration  of  the  Static  Scheduler  will  determine  whether  these 
Ada®  constructs  are  sufficient  and  effective  in  meeting  the  critical  timing  constraints  of 
hard  real-time  or  embedded  systems. 

Recognizing  the  increased  cost  and  importance  of  software  development  for  Com¬ 
mand  and  Control  systems,  the  Secretary  of  the  Navy  (SECNAV)  promulgated  a  new 
instruction  addressing  software  development  and  acquisition  (sec  Ref.  IS).  This  in¬ 
struction  documents  SECNAV  concern  for  defining  a  DON  acquisition  policy  for  soft¬ 
ware-intensive  systems  and  increasing  user  involvement  during  the  design  and 
development  stages.  The  policy  combining  these  two  concerns  states 


To  promote  effective  interaction  between  the  user  and  the  developer,  software  pro¬ 
totyping  methods  shall  be  used  in  the  design  and  construction  ol  C2  inldtmat.on 
systems.  Early  deli',  ery  of  software  systems  is  emphasized  through  the  use  of  pro¬ 
totyping  methods.  [Ref.  IS:  p.  2| 


The  instruction  defines  software  prototypes  identical  to  that  used  throughout  tins  thesis 
as 


Software  which  stimulates  the  important  interfaces  and  performs  the  main  functions 
of  the  intended  system  while  not  being  bound  by  the  same  hardware,  speed,  size  or 
cost  constraints.  It  may  serve  to  demonstrate  or  provide  a  subset  of  tiie  functions 
that  would  be  required  of  software  to  meet  a  related,  fullv-validatcd  requirement. 
[Ref.  IS:  pp.  1-2] 


Computer-aided  rapid  prototyping  specifically  addresses  the  concerns  of  the  SECNAV. 
In  particular,  the  CAPS  stresses  interaction  between  the  software  designer  and  the  user 
early  in  the  design  and  development  stages.  This  allows  validation  of  the  piotoiype  s 
ability  to  simulate  the  critical  interfaces  and  functions  of  the  envisioned  system.  The 
author  agrees  that  the  increased  cost  and  complexity  of  developing  software  warrants  a 
revised  approach  to  the  software  acquisition  procedures. 

Concurrent  research  projects  to  conceptualize  components  of  the  CAPS  Execution 
Support  System  are  now  complete.  These  individual  efforts  empirically  demonstrate  that 
the  initial  goal  of  providing  an  automated  execution  environment  for  a  software  design 
or  specification  prototypes  is  feasible.  The  CAPS  will  provide  software  designers  with 
an  automated  tool  which  allows  validation  of  prototypes  for  hard  real-time  or  embedded 
systems  before  extensive  time  and  money  are  invested  in  production  software.  Addi¬ 
tional  research  projects  are  currently  underway  to  conceptualize,  implement  and  inte¬ 
grate  the  various  components  or  subsystems  of  CAPS.  The  time  and  effort  expended 
today  toward  a  formal  demonstration  of  the  CAPS,  together  with  increased  usage  of  the 
Ada®  programming  language,  promise  a  future  rapid  prototyping  environment  which 
meets  the  demanding  needs  of  the  DOE)  and  DON  software  procurement  and  develop- 
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APPENDIX  A.  PSDL  GRAMMAR 

Optional  items  are  enclosed  in  [  square  brackets  ]  and  items 
that  may  appear  zero  or  more  times  appear  in  (  braces  } 

Terminal  symbols  appear  in  "  double  quotes 

psdl  =  {  component  } 

component  =  data_type 
|  operator 

data_type  =  "type"  id  type_spec  type_impl 

operator  =  "operator"  id  operator_spec  operator_impl 

type_spec  =  "specification"  [  type_decl  ] 

{  operator"  id  operator_spec  } 

[  functionality  ]  "end" 

operator_spec  =  "specification"  interface 
[  functionality  ]  "end" 


interface  =  {  attribute  [  reqmts_trace  ]  } 


attribute  =  generic_param 
|  input 
j  output 
j  states 
j  exceptions 
|  timing_info 

generic_param  =  "generic"  type_decl 


input  =  "input"  type_decl 
output  =  "output"  type_decl 

states  =  "states"  type_decl  "initially"  expression_list 


exceptions  =  "exception"  id_list 
id_list  =  id  {  ","  id  } 


timing_info  =  [  "maximum 
[  "minimum 
[  "maximum 


execution  time"  time  ] 
calling  period"  time  ] 
response  time"  time  ] 


time  =  integer  [  unit  J 


unit 


M 

II 

II 

II 


microsec" 

ms" 

sec" 

min" 
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|  "hours" 


reqmts_trace  =  "by  requirements"  id_list 

functionality  =  [  keywords  ] 

[  informal_desc  ] 

[  formal_desc  ] 

keywords  =  "keywords"  id_list 

informal_desc  =  "description"  "  {  "  text  "  }  " 


formal  desc  =  "axioms' 


text  } 


type_impl  -  "implementation"  "Ada"  id 
|  "implementation"  type_name 

{  "operator"  id  operator_impl  }  "end" 

operator_impl  =  "implementation"  "Ada"  id 
|  "implementation"  psdl_.impl 

psdl_impl  =  data_f low_diagram 
[  streams  ] 

[  timers  ] 

[  control_constraints  ] 

[  informal  desc  ] 

"end" 

data_f low_diagram  =  "graph"  {  link  } 
link  =  id  op_id  "->"  id 
op_id  =  id  [  ":  "  time  ] 
streams  =  "data  stream"  type_decl 

type_decl  =  id_list  "  type_name  {  id_list  ":  "  type_name  } 

type  name  =  id 

|  id  "  [  "  type_decl  "  ]  " 

timers  =  "timer"  id_list 

control_constraints  =  "control  constraints"  {  constraint  } 

constraint  =  "operator"  id  ( 

[  "triggered"  [  trigger  ]  [  "if"  predicate  ] 

[  reqmts_trace  ]  ] 

[  "period"  time  £  reqmts_trace  J  ] 

[  "finish  within'  time  [_  reqmts_trace  ]  ] 

}  "output”  id_list  "if"  predicate 
f  reqmts_trace  ]  j 

{  "exception"  id  [  "if"  predicate  ] 

[  reqmts^race^  ]  j 
f  timer_op  id  [  "if"  predicate  ] 
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timer_op  =  "RESET  timer" 

|  "START  timer" 
j  "STOP  timer" 

|  "READ  timer" 

trigger  =  "by  all"  id_list 
|  "by  some"  icl_list 

predicate  =  "not"  predicate 

|  predicate  "and"  predicate 
|  predicate  "or"  predicate 
|  expression 
|  id  id_lis t 

expression  =  constant 

I 

j  type_name  id  "("  expression_list 

express ion_list  =  [  expression  {  " expression  } 


VJTV.  tOHCTCT  T&BFSF&WVXVHFVF3?  gJTTi*7TV7  g  gWTCP 


APPENDIX  B.  HYPERTHERMIA  SYSTEM 

This  appendix  contains  the  PSDL  source  program  for  the  Hyperthermia  System  as 
created  by  the  designer  and  the  user.  This  program  does  not  represent  all  aspects  of  the 
final  envisioned  system.  As  required  for  prototype  development  with  the  Computer 
Aided  Prototyping  System  (CAPS),  this  PSDL  program  contains  only  those  attributes 
and  functions  that  are  required  to  simulate  the  critical  timing  characteristics  of  the  sys- 


OPERATOR  brain_tumor_treatment_system 
SPECIFICATION 

INPUT  patient_chart:  medical_history , 
treatment_switch:  boolean 

OUTPUT  treatment_f inished:  boolean 
STATES  temperature:  real 
INITIALLY  37.0 
DESCRIPTION 

{  The  brain  tumor  treatment  system  kills  tumor  cells 
by  means  of  hyperthermia  induced  by  microwaves. 

END 

IMPLEMENTATION 

GRAPH 


S I nULRTED_PRT I  ENT 


TEnPEflHTURE 


PflT I EMT_CHHRT 
TRERTItEMT_SUITCH 


HYPERTHERII I  fl_SVSTE?1 


TREflTnEMT_PDUER 


TRERTHEMT_F I H I  SHED 


DATA  STREAM  treatment_power:  real 
CONTROL  CONSTRAINTS 
OPERATOR  hyper thermia_system 
PERIOD  200  BY  REQUIREMENTS  shutdown 
OPERATOR  simulated_patient 


1 


PERIOD  200 

DESCRIPTION  {  paraphrased  output  } 
END 


TYPE  medical_history 
SPECIFICATION 

OPERATOR  get  tumor  diameter 
SPECIFICATION 

INPUT  patient_chart:  medical_history , 
tumor_location:  string 

OUTPUT  diameter:  real 
EXCEPTIONS  no_tumor 
MAXIMUM  EXECUTION  TIME  5  ms 
DESCRIPTION 

{  Returns  the  diameter  of  the  tumor  at  a  given  location, 
produces  an  exception  if  no  tumor  at  that  location. 

END 


KEYWORDS  patient_charts ,  medical_records ,  treatment_records , 
lab  records 
DESCRIPTION 

{  The  medical  history  contains  all  of  the  disease  and 
treatment  information  for  one  patient.  The  operations 
for  adding  and  retrieving  information  not  needed  by 
the  hyperthermia  system  are  not  shown  here. 


IMPLEMENTATION 

tuple  [ tumor_desc:  map[ from: 

OPERATOR  get  tumor_diameter 
IMPLEMENTATION 
GRAPH 


string,  to:  realj  , 


PRT  I  EMT_CHRRT 


TUPLE .  GET_TUriOR_DESC 


TUI10R— LOCRT  I  OH 


RAP. FETCH 


OIRRETER 


(WWW 


DATA  STREAM  td:  tumor_descr 
CONTROL  CONSTRAINTS 
OPERATOR  map. fetch 

EXCEPTIONS  no_tumor  IF  not(map. has( tumor_location,  td)) 

END 


END 


OPERATOR  hyperthermia_system 
SPECIFICATION 

INPUT  temperature:  real,  patient_chart:  medicaI_history , 
treatment_switch:  boolean 

OUTPUT  treatment_power:  real,  treatment_f inished:  boolean 
MAXIMUM  EXECUTION  TIME  100  ms 
BY  REQUIREMENTS  temperature_tolerance 
MAXIMUM  RESPONSE  TIME  300  ms 
BY  REQUIREMENTS  shutdown 
KEYWORDS  medical_equipment ,  temperature_controI , 
hyperthermia,  brain_tumors 
DESCRIPTION 

{  After  the  doctor  turns  on  the  treatment  switch,  the 
hyperthermia  system  reads  the  patient's  medical  record 
and  turns  on  the  microwave  generator  to  heat  the  tumor 
in  the  patient's  brain.  The  system  controls  the  power 
level  to  maintain  the  hyperthermia  temperature  of 
42.5  degrees  C.  for  45  minutes  to  kill  the  tumor  cells. 
Iv'hen  the  treatment  is  over,  the  system  turns  off  the 
power  and  notifies  the  doctor. 

1 

END 


IMPLEMENTATION 
GRAPH  90 


DATA  STREAM  estimated_power:  real 
TIMER  treatment_time 
CONTROL  CONSTRAINTS 
OPERATOR  start_up 
TRIGGERED  IF  temperature  <  42. 4 
3Y  REQUIREMENTS  maximum_temperature 
STOP  TIMER  treatment_time 

RESET  TIMER  treatment_time  IF  temperature  <=  37. 0 

OPERATOR  maintain 
TRIGGERED  IF  temperature  >=  42.  4 
BY  REQUIREMENTS  maximum_temperature 
START  TIMER  treaLment_time 

BY  REQUIREMENTS  treatment_time ,  temperature_toleranc.e 
OUTPUT  treatment_finished  IF  treatment_time  >=  45  min 
BY  REQUIREMENTS  treatment_time 

END 


OPERATOR  start_up 
SPECIFICATION 

INPUT  patient_chart:  medical_liistory ,  temperature:  real 
OUTPUT  estimated_power:  real,  treatment_finished:  boolean 
BY  REQUIREMENTS  startup_time 
MAXIMUM  EXECUTION  TIME  90  ms 
BY  REQUIREMENTS  temperature_tolerance 
DESCRIPTION 

{  Extracts  the  tumor  diameter  from  the  medical  history  and 
uses  it  to  calculate  the  maximum  safe  treatment  power. 
Estimated-power  is  zero  if  no  tumor  is  present.  The 
treatment  finished  is  true  only  if  no  tumor  is  present. 

END 


IMPLEMENTATION  Ada  start_up 
END 


OPERATOR  maintain 
SPECIFICATION 
INPUT  temperature:  real 

OUTPUT  estimated_power:  real,  treatment  finished:  boolean 
MAXIMUM  EXECUTION  TIME  90  ms 
BY  REQUIREMENTS  teinperature_tolerance 
DESCRIPTION 

{  The  power  is  controlled  to  keep  the  power  between  42.4 
and  42. 6  degrees  C. 

I 

END 


IMPLEMENTATION  Ada  maintain 
END 


OPERATOR  safety_control 
SPECIFICATION 

INPUT  treatment_switch ,  treatment_f inished:  boolean 
estimated_power:  real 

OUTPUT  treatment  power:  real 
BY  REQUIREMENTS  shutdown 
MAXIMUM  EXECUTION  TIME  10  ms 
BY  REQUIREMENTS  temperature_tolerance 
DESCRIPTION 

{  The  treatment  power  is  equal  to  the  estimated  power 
if  the  treatment  switch  is  true  and  treatment  finished 
is  false.  Otherwise  the  treatment  power  is  zero. 

END 


IMPLEMENTATION  Ada  start_up 
END 
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ArPENDIX  C.  STATIC  SCHEDULER  DATA  FLOW  DIAGRAMS 

This  appendix  contains  the  Data  How  Diagrams  (DFDs)  for  the  Static  Scheduler. 
The  1st  and  2nd  level  DFDs  from  Reference  15  provide  the  groundwork  for  describing 
the  Static  Scheduler  in  Chapter  III.  The  lower  level  diagrams  represent  the  pioneering 
efforts  for  implementing  the  Static  Scheduler  in  Chapter  IV  of  this  thesis. 
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OPERATOR . 
FILE 


f  BUILD. 
HARMONIC. 
V  BLOCKS 


HARMONIC 
-  BLOCK 
LENGTH 


/  CALC.  \ 

/  SORT  \ 

/  FIND  \  / 

/  PERIODIC.  ] _ , 

J  by.  y- 

-W  base.  V— w 

\  EQUIV  ALENT J 

V  PERIOD  J 

V  BLOCKS  j  \ 

FIND. 

BLOCK. 

LENGTH 


Figure  24.  2nd  Level  DFD  /,Duild_IIarmonic_Blocks// 


OPERATOR. 

FILE 


/  CALC.  \ 
'  PERIODIC. 

^equivalents; 


PERIODIC 

OPERATORS 


f LOCATE.  \ 

(  CHECK 

\N 

/  CREATE.  \ _ 

CALC.  \ 

1  SPORADIC.  ) - 

M  FOR. 

)—* 

\  MRT  J 

M  PERIOD  / 

\OPERATOR  J 

V  MRT 

/ 

V  / 

figure  25. 


3rd  Level  DFD  "Caic_Periodic_Lquivalents" 


iV*V 


PERIOD 

OPERATORS 


Figure  28.  3rd  Level  DFD  "Sort_by_Feriod" 


SORTED 


PERIODICS 


a 
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Figure  40.  4th  Level  DFD  "Create_Intervaj 


figure  41.  3rd  Level  DFD  "Scliedule_Rest_i>f_Bluck 


Figure  42.  4th  Level  DFD  "Verify  Lower" 


1  igurc  43.  4lh  Level  DFD  "Create  Interval" 


APPENDIX  D.  AG  PROCESSOR  SOURCE  PROGRAM 


The  following  AG  Processor  source  code  represents  an  adaptation  of  the  Kodiyak 
AG  translator  generator  specifically  designed  for  the  Static  Scheduler.  Its  primary  ob¬ 
jective  is  identification  and  retrieval  of  only  the  critical  operators  and  their  timing  con¬ 
straints  from  the  PSDL  prototype  source  program. 


?bdefine  Digit 
%define  Int 
%define  Letter 
^define  Alpha 
"define  Blank 
"define  Char 


TYPE 

OPERATOR 

SPECIFICATION 

END 

GENERIC 

INPUT 

OUTPUT 

STATES 

INITIALLY 

EXCEPTIONS 

MAX_EXE  C_T I ME 

MAX_RE  S  P_T I ME 

MIN_CALL_PERIOD 

BY 

KEYWORDS 

DESCRIPTION 

AXIOMS 

TEXT 

IMPLEMENTATION 

GRAPH 

DATA.STREAM 

TIMER 

CONTROL 

TRIGGERED 

IF 

PERIOD 

FINISH 

OUTPUT 

EXCEPTION 

RESET 

START 


: CO-9] 

:  |Digit]  + 

:  [a-zA-Z_] 

:  ({Letter}  |  (Digit}) 

:  [  \t\n] 

:  {Blank}+ 

: type | TYPE 
:  operator | OPERATOR 
: specification | SPECIFICATION 
: end | END 

:  generic | GENERIC 
: input j INPUT 
: output | OUTPUT 
: states | STATES 
: initially | INITIALLY 
: exceptions | EXCEPTIONS 
:  iuaximum[  Jexecutionf  ]time 
|MAXIMUM[  ]EXEOUTION[  ]TI!1E 
: maximura[  ]response[  ]time 
| MAX I MUM [  ]RESPONSE[  ]TIME 
:minimum[  ]calling[  ]period 
i MINIMUM[  ]CALLING[  ]PERIOD 
:  by[  ]requiremeuts | BY[  ] REQUIREMENTS 
:  keywords  |  KEYWORDS 
: description | DESCRIPTION 
: axioms | AXIOMS 
:  {Char}* 

:  implementation! IMPLEMENTATION 
: graph (GRAPH 

: data[  ]st ream | DATA[  ]STREAM 
:  timer | TIMER 

: control[  ]constraints | CONTROL[  JCONSTRAINTS 
: triggered | TRIGGERED 
:  if  |  IF 

: period | PERIOD 

:  firiishf  Jwithin|FINlSH[  ] WITHIN 
: output | OUTPUT 
: exception | EXCEPTION 
:  reset | RESET 
:  start | START 


t’i 
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STOP 

ALL 

SOME 

MICROSEC 

MS 

SEC 

MIN 

HOURS 

ADA 

ARROW 

TRUE 

FALSE 


: stop | STOP 
:  by[  Jail  |  3Y[  JALL 
:  by[  Jsome  |  PY[  JSOME 
: microsec | MICROSEC 
:  ms  |  MS 
: sec | SEC 
: min  j  MIN 
: hours | HOURS 
: ada| Ada | ADA 
11  ->M 

: true | TRUE 
: false  I  FALSE 


AND 

"■Sc"  | 

"and" 

| "AND" 

OR 

'T'l 

"or"  | 

"OR" 

NOT 

ft  t!  | 
~  1 

"not" 

| "NOT" 

ID 

{Lc  t 

ter}{Alpha}* 

INTEGER_LITERAL 

;Inc 

} 

REAL.LITERAL  :  {Int}".  "{Int} 

!  operator  precedences 
%lef t 

%left  OR; 

%left  AND; 

%left  NOT; 

%% 

!  attribute  declarations  for  nonterminal  symbols 

start  {  trn:  string;  }; 
psdl  {  trn:  string;  }; 
component  {  trn:  string;  }; 
data_type  {  trn:  string;  }; 
operator  {  trn:  string;  }; 
type_spec  {  trn:  string;  }; 
op t iona l_type_dec 1  {  trn:  string;  }; 
op_list  {  trn:  string;  ); 
operator_spec  {  trn:  string;  }; 
interface  {  trn:  string;  }; 
attribute  {  trn:  string;  }; 
attribute_list  {  trn:  string;  }; 
generic_param  {  trn:  string;  }; 
input  {  trn:  string;  }; 
output  {  trn:  string,  }; 
states  {  trn:  string;  }; 
exceptions  {  trn:  string;  }; 
id_list  {  trn:  string;  ); 
ma;c_exec_timo  {  trn:  string;  }; 
max_resp_time  {  trn:  string;  }; 
inin_period  {  trn:  string;  ); 
time  {  value:  int; 

trn:  string;  ); 
unit  {  trn:  string;  }; 


mm 

reqmts_trac3  !  trn:  string;  ]; 
functionality  (  trn:  string;  }; 
keywords  {  trn:  string;  ); 
informal_desc  {  trn:  string;  }; 
forma l_desc  {  trn:  string;  }; 
type_impl  {  trn:  string;  }; 
op_impl_list  {  trn:  string;  }; 
operator_impl  {  trn:  string;  }; 
psdl_impl  {  trn:  string;  }; 
data_f low_diag.ram  [  trn:  string;  }; 
links  {  trn:  string;  }; 
streams  {  trn:  string;  }; 
type_decl  {  trn:  string;  }; 
type_name  {  trn:  string;  }; 
timers  !  trn:  string;  }; 
control_constraints  {  trn:  string;  }; 
constraints  {  trn:  string;  }; 
constraint  {  trn:  string;  }; 
trigger  (  trn:  string;  ]; 
cond  {  trn:  string;  ); 
period  {  trn:  string;  J; 
finish  {  trn:  string;  }; 
outputs  {  trn:  string;  }; 
exception_ops  {  trn:  string;  }; 
timer_ops  {  trn:  string;  }; 
timer_op  {  trn:  string;  }; 
opt_trigger_constraint  {  trn:  string;  }; 
predicate  {  trn:  string;  }; 
expression  {  trn:  string;  }; 
expression_list  {  trn:  string;  }; 
op_id  {  trn:  string;  }; 
opt_reqmts_trace  {  trn:  string;  }; 
opt_unit  {  value:  int; 

trn:  string;  }; 

opt_keywords  {  trn:  string;  }; 
opt_formal_desc  {  trn:  string;  }; 
opt_informal_desc  {  trn:  string;  }; 
opt_streams  f  trn:  string;  J; 
opt_timers  {  trn:  string;  }; 
opt_control_constraints  {  trn:  string;  }; 
opt_time  {  trn:  string;  }; 
opt_trigger  {  trn:  string;  }; 
opt_cond  f  trn:  string;  ); 
opt_period  {  trn:  string;  J; 
opt_finish  {  trn:  string;  }; 

! attrbute  declarations  for  terminal  symbols 

ID  {  %text:  string;  }; 

INTEGER_LITERAL  {  ?itext:  string;  i; 
REAI._I,ITERAL  {  %text:  string;  j; 


O'  Of 
too 

! psdl  grammar 


start 


S3 


Vr %"TV 


:  psdl 

{  %output( psdl.  trn);  } 


:  psdl  component 

{  psdl[l].  trn  =  [  psdl[2j.  trn , component,  trn  ];  } 


{  psdl[l],  trn  =  } 


component 


:  data_type 

{  component,  trn  =  } 

|  operator 

{  component,  trn  =  operator. trn;  } 


data_type 


:  TYPE  ID  type_spec  tvpe_inipl 
{  data_type.  trn  =  "lf;  } 


operator 


:  OPERATOR  ID  operator_spec  operator_impl 

{  operator,  trn  =  ["ID  , ID.  %text ,operator_spec. trn, 
operator_impl.  trn];  } 


type_spec 


:  SPECIFICATION  optional_type_decl  op_list  functionality  END 
{  type_spec.  trn  =  [  optional_type_decl. trn,op_list. trn, 

functionality. trn  ];  } 


optional_type_decl 
:  type_decl 

{  optional_type_decl.  trn  =  type_decl. trn;  } 


op_list 


{  optional_type_decl.  trn  =  } 


:  op_list  OPERATOR  ID  operator_spec 
{  op_lis  t[l].  trn  =  } 


{  op_l.ist[l],  trn  =  J 


operator_spec 

:  SPECIFICATION  interface  functionality  END 

{  operator_spec. trn  =  [  "SPEC  ",  interface. trn, "END  "  ]; 


% 

■si 
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interface 


:  attribute_list 

{  interface[l],  trn  =  attr ibute_list.  trn;  1 


attribute_list 

:  attribute_list  attribute  opt_reqmts_trace 

{  attribute_list[lj. trn  =  [attribute_list[2]. trn, 

attribute. trn,opt_reqmts_trace.  trnj; 


{  attribute_list. trn  =  "  ;  } 


opt_reqmts_trace 

:  reqmts_trace 

{  opt_reqmts_trace.  trn  =  reqmts_trace.  trn;  } 
{  opt_reqmts_trace. trn  =  } 


attribute 


:  generic_param 

{  attribute,  trn  =  } 

|  input 

{  attribute,  trn  =  } 

|  output 

{  attribute,  trn  =  } 

|  states 

{  attribute,  trn  =  states,  trn;  } 

|  exceptions 

{  attribute,  trn  =  } 

|  raa’x_exec_time 

{  attribute. trn  =  max_exec_time.  trn;  } 
|  max_resp_time 

(  attribute,  trn  =  max_resp_tiine.  trn;  ) 
|  min_period 

{  attribute. trn  =  min_period. trn;  } 


generic_param 

:  GENERIC  type_decl 

{  generic_param.  trn  =  type_dec 1. trn; 


input 


output 


states 


:  INPUT  type_decl 

'  input. trn  =  type_decl.  trn;  } 


:  OUTPUT  type_decl 

}  output. trn  =  type_decl. trn; 


:  STATES  type_decl  INITIALLY  express ion_l is t 


fnViti 


ay  v.  v.  v;  'y.y.' 


X 


{  states. trn  =  [  "STATE  " , type_decl. trn  ];  } 

J 

1 

exceptions 

:  EXCEPTIONS  id_list 

{  exceptions,  trn  =  [  "JUNK  " , id_l ist. trn  ];  } 

t 

1 A 

» 

*  «r 

SI 

/j 

id_list 

:  id_lis  c  ' , '  ID 

{  id  list[l].  trn  =  "";  } 

1  ID 

{  id_Iist[l].  trn  =  ID.  %text;  } 

> 

J-] 

max  exec  time 

:  MAX_EXEC_TIME  time 

i  max_exec_t ime.  trn  =  ["MET  ”, i2s( time,  trn)];  } 

f 

1 

1 

max_resp_time 

:  MAX_RE S P_T I ME  time 

{  max_resp_time.  trn  =  ["HRT  ", i2s( time. trn)];  ] 

> 

Jj, 

1 

l 

min  period 

:  MIN_CALL_PERIOD  time 

{  min_period.  trn  =  ["MCP  ", i2s( time. trn)];  } 

5 

1 

time 

:  INTEGER_LITEFAL  opt_unit 

{  time,  trn  =  s2i( INTEGER_LITERAL.  %text)  *  opt_unit. value; 

time,  trn  =  i2s  ( time. value);  } 

> 

l 

£ 

opt_unit 

:  unit 

{  opt_unit.  trn  =  unit,  trn;  ) 

<r- 

IN 

5 

{  opt_unit.  trn  =  } 

> 

3 

unit 

:  MICROSEC 

{  unit,  trn  =  " l";  } 

(MS 

{  unit,  trn  =  "1000";  } 

|  SEC 

(  unit. trn  =  "lOOOOOO";  } 

|  MIN 

(  unit,  trn  =  "60000000";  } 

|  HOURS 

{  unit. trn  =  "3600000000";  } 

y 

> 

s 

'.V 

£ 

• 
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reqmts  trace 

:  BY  j.d_l  1st 

{  reqmts_trace.  trn  =  [  "JUNK  " ,  id_list.  trn  ];  } 


functionality 

:  opt_keywords  opt_informal_desc  opt_formal_desc 

{  functionality,  trn  =  [  op t_key words.  trn , opt_informal_desc.  trn, 

opt_formal_desc.  trn  ];  } 


opt_keywords 

:  keywords 

{  opt_keywords.  trn  =  keywords. trn;  } 


{  opt_keywords.  trn  =  } 


opt_informal_desc. 

:  i.nformal_desc 

'  opt_informal_desc.  trn  =  informal_desc. trn;  ] 


{  opt_informal_desc.  trn  =  } 


opt_formal_desc 

:  forraal_desc 

{  opt_formal_desc.  trn  =  formal_desc.  trn;  } 
{  opt_formal_desc.  trn  =  } 


keywords 


:  KEYWORDS  id_list 

{  keywords,  trn  =  [  "JUNK  " , id_list.  trn  ]; 


informal_desc 

:  DESCRIPTION  TEXT 

r  _ „  1  i _ _ _ _  II »». 


{  informal_desc.  trn  =  ;  } 


formal  desc 


:  AXIOMS  TEXT 

{  formal_desc.  trn  =  } 


type_irnpl 


:  IMPLEMENTATION  ADA  ID 
{  tvpe_iinpl.  trn  =  ! 

|  IMPLEMENTATION  type_name  op_impl_list  END 

{  type_impl.  trn  =  [type_name.  trn,op_impl_list.  trnj; 


op_impl_list 

:  op_impl_list  OPERATOR  ID  operator_impl 
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{  op_impl_list[l'J.  trn  = 

I  "JUNK  " ,operator_impl.  trn  [;  J 

{  op_impl_list[l].  trn  =  "";  } 


operator_impl 

:  IMPLEMENTATION  ADA  ID 

{  operator_lmpl.  trn  =  "ADA  } 

|  IMPLEMENTATION  psdl_impL 
{  operator_impl.  trn  =  ["IMPL  " ,psdi_impl.  trn];  } 

1 

psdl_impl 

:  data_f low_diagram  opt_streams  opt_tiraers  opt_control_constraints 
opt_informal_desc  END 

{  psdl_impl.  trn  =  [data_f low_diagram.  trn ,opt_streams.  trn, 

opt_timers.  trn,opU_informai_desc.  trn, 
opt_controL  constraints,  trn, "END  "];  ' 

I 

{  psdl_impl. trn  =  } 


data_f low_diagram 

:  GRAPH  links 

{  data_f low_diagram.  trn  =  links. trn;  } 


links 

:  links  ID  ' . '  op_id  ARROW  ID 

{  links[lj.  trn  =  ["LINK  " ,  ID.  %text , "  .  ",  op  id.  trn, 
"ARROW  "  ,  ID.  %text];  } 

{  links[l].  trn  =  "";  ] 


op_id 

:  ID  ' : '  opt_time 

{  op_id.  trn  =  [ID.%text,"  :  " ,opt  time,  trn];  } 

I  ID 

{  op_id.  trn  =  ID. %text;  } 


opt_time 

:  time 

{  opt_time.  trn  =  time. trn;  } 
{  opt_time.  trn  =  } 


opt_streams 

:  streams 

{  opt_streams. trn  =  streams. trn; 


{  opt_streams.  trn  “ 


opt_timers 


timers 

{  opt_timers.  trn  =  timers. trn;  j 


opt_timers.  trn  =  } 


op t_con  t  r o l_cons  t  r  a in  t  s 

:  control_constraints 

{  opt_control_constraints.  trn  =  control_constraints.  trn; 


opt_control_constraints.  trn  =  } 


streams 


DATA_STREAM  type_decl 
{  streams. trn  =  type_decl. trn;  J 


type_decl 


type_dec.l  id_list  type_nnme 

{  type_decl[l].  trn  =  [  "JUNK  ,id_ list,  trn  ]; 
id_iist  type_name 

{  type_decl[lj.  trn  =  [  "JUNK  ",id_list.  trn  j; 


type_name 


ID 


f  type_name.  trn  =  "";  } 
ID  '  ['  type_decl  1  ]' 

{  type_name.  trn  =  } 


timers 


TIMER  id_list 

{  timers,  trn  =  [  "JUNK  " , id_list.  trn  ];  } 


control_constraints 

:  CONTROL  constraints 

{  control_constraints.  trn  =  constraints,  trn; 


constraints 

:  constraints  constraint 

{  constraints[l].  trn  =  [  constraints[2J.  trn , 

constraint,  trn  j;  } 


{  constraints,  trn  =  } 


constraint 

:  OPERATOR  ID  opt_trigger_constraint  opt_period 
opt_finish  outputs  exception_ops  timer_ops 

{  constraint[l].  trn  =  ["ID  " , ID. %text ,opt_trigger_constraint.  trn , 


89 


a 

r. 


» 


opt_period.  trn  ,opt_f inis'a.  trn, outputs.  crn, 
except ion_ops.  trn ,  Limer_ops.  tr:i  j;  } 


opt_trigger 


trigger 

{  op t_t rigger,  trn 


=  trigger. trn; 


{  opt_trigger.  trn  = 


opt_period 

:  period 

{  opt_period. trn  =  period. trn;  } 


{  opt_period.  trn  =  } 


opt_f inish 

:  finish 

{  opt_finish. trn  =  finish. trn;  } 
{  opt_finish.  trn  =  } 


opt_cond 


cond 

{  opt_cond.  trn  =  cond.  trn; 
{  opt_cond.  trn  =  } 


} 


opt_trigger_constraint 

:  TRIGGERED  opt_trigger  opt_cond  opt_reqmts_trace 

{  opt_trigger_constraint.  trn  =  [  opt_trigger.  trn,opt_cond. trn, 

opt_reqmts_trace. trn  ];  } 

{  opt_trigger_constraint. trn  =  } 


cond 

:  IF  predicate 

{  cond. trn  =  predicate,  trn;  } 


period 

: PERIOD  time  opt_reqrats_trace 
}  period. trn  =  ["PERIOD  ",  time,  trn, opt_reqmts_trace.  trn];  } 


finish 

:  FINISH  time  opt_reqmts_trace 
{  finish,  trn  =  ["FINISH  ",  time,  trn, opt_reqmts_trace.  trn];  } 


outputs 


:  outputs  OUTPUT  id_list  cond  opt_reqmts_trace 
{  outputs[l].  trn  =  [  "JUNK  " ,  i>I_!ist.  trn  ,coud.  trn, 

opt_reqmts_trace.  trn  ];  } 

{  outputs[l].  trn  =  } 


I 


except ion_ops 

:  exception_ops  EXCEPTION  ID  opt_cond  opt_reqmts_trace 
{  exception_ops[l].  trn  =  [  opt_cond. trn, 

opt_reqrnts_trace.  trn  ];  } 

I 


{  exception_ops[l]. trn  =  ;  } 


timer_ops 


:  timer_ops  timer_op  ID  opt_cond  opt_reqmts_trace 
{  timer_ops[l].  trn  =  [  timer_op. trn,opt_cond.  trn, 

opt_reqniC3_trace.  trn  ];  } 

{  timer_ops[l].  trn  =  } 


y 


timer_op 


:  RESET 

{  timer  op. trn  =  ;  } 

START 

{  timer_op.  trn  =  } 

STOP 

{  timer_op.  trn  =  } 


■;  expression,  crn  =  "" 
FALSE 

{  expression,  trn  =  "" 
ID 

{  expression,  trn  =  "" 
type_name  1 . 1  ID  ' ( ' 

{  expression. trn  =  "" 


expression_list  ')' 


express ion_l ist 

:  expression_list  expression 
{  expression_list[l],  trri  =  } 

|  expression 

{  expression_list[l]. trn  =  } 


m 


i 
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APPENDIX  E.  STATIC  SCHEDULER  PSEUDOCODE  LISTING 

The  following  Static  Scheduler  pseudocode  represents  a  guideline  for  implementing 
an  executable  Ada®  program.  Precise  naming  conventions  for  program  units,  file  and 
data  tvpes,  and  .Ada®  EXCEPTIONS  specifically  relate  to  the  Static  Scheduler.  Chap¬ 
ters  III  and  IV  of  this  thesis  outline  the  underlying  assumptions  and  concerns  that  were 
considered  during  development  of  this  pseudocode. 

package  FILES  is 


type  MRT  is  VALUE; 
type  MCP  is  VALUE; 
type  PERIOD  is  VALUE; 
type  WITHIN  is  VALUE; 
type  STARTS  is  VALUE; 
type  STOPS  is  VALUE; 
type  LOWERS  is  VALUE; 
type  UPPERS  is  VALUE; 

type  LINKS  is 
record 

THE  DATA  STREAM 
THE  FIRST.OP  ID 
THE  LINK  MET 
THE_SECOND_OP_ID 
end  record; 

type  OPERATORS  is 
record 

THE  OPERATOR_ID 
THE_MET 
THE  MRT 
THEJiCP 
THE  PERIOD 
THEJv'ITHIN 
end  record; 


DATA_STREAM; 
OPERATOR  ID; 
MET  ;=  0; 
OPERATOR.ID; 


OPERATOR_ID; 
MET  :=  0; 

MRT  :=  0; 

MCP  :=  0; 
PERIOD  :=  0; 
WITHIN  :=  0; 


type  FRECEDENCE_LIST  is 
record 

THE_LEFT  0P_ID  ;  OPERATORS D; 

THE_RIGHT_OP_ID  :  0PERAT0R_I1); 

end  record; 

type  SCIIEDULE_INPUTS  is 
record 


I 


OPERATOR 

:  OPERATOR 

o 

1—4 

1 

THE  START 

:  STARTS 

=  0; 

THE  STOP 

:  STOPS 

=  0; 

THE  LOWER 

:  LOWERS 

=  0; 

THE  UPPER 

:  UPPERS 

=  0; 

end  record; 


end  FILES; 


with  TEXT.IO; 
package  PSDL_READER  is 

procedure  INVOKE_AG_PROCESSOR  (  PSDL_PROG  ;  TEXT_IO.  IN_FILE; 

AG_OUTF  1 LE  :  TEXT.IO.  OUT.FILE  ); 
procedure  READ.THE.FILE  (  AG.OUTFILE  :  TEXT.IO.  OUT_FILE  ); 

end  PSDL.READER; 


with  TEXT.IO; 
with  FILES; 

package  FILE.PROCESSOR  is 


procedure  SEPARATE.DATA  ( AG.OUTF I LE 

LINKS 

OPERATORS 

NON.CRITS 

procedure  VALIDATE.DAT A  (  OPERATORS 


TEXT.IO.  IN.FILE; 
TEXT.IO. OUT.FILE; 
TEXT.IO.  OUT.FILE; 
TEXT.IO.  OUT.FILE  ); 
TEXT.IO.  IN.FILE  ); 


MET.EQUALS.PERIOD  ;  exception; 
MET.NOT_LESS_THAN.MRT  :  exception; 


end  FILE.PROCESSOR; 


with  FILES; 
with  TEXT.IO; 

package  TOPOLOGICAL.SORTER  is 

procedure  CREATE.LISTS  (  LINKS  :  TEXT.IO. IN  FILE; 

PRECEDENCE  LIST  :  TEXT.IO.  OUT.FILE  ); 
procedure  SORT.REMAINING.OPERATORS  (  PRECEDENCE.LIST  : 

TEXT.IO.  OUT  FILE; 
LINKS  :  TEXT  10.  IN.FILE  ); 


NO.INJTIAL  LINK  OP  :  exception; 
NO.MATCIIES.FOUND  :  exception; 


end  TOPOLOGICAL.SORTER; 
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with  FILES; 

package  HARMON I C_B LOG K_BU I LDE R  is 

procedure  CALC.PERIODIC.EQUIVALENTS  (  OPERATORS  :  TEXT. 10.  IN_FILE  ); 
procedure  SORT_BY_PERiOD  (  THE  PERIOD  :  in  out  OPERATORS  ); 
procedure  FIND. BASE  BLOCK  (  THE.PERIOD  :  in  out  OPERATORS; 

BASE  BLOCK  :  out  INTEGER  ); 

procedure  FIND  BLOCK. LENGTH  (  BASE  BLOCK  :  in  out  INTEGER; 

HARMONIC.BLOCK.LENGTH  :  out  INTEGER  ); 


CONSTRAINTS  INVALID 
NO.BASE.BLOCK 


exception; 

exception; 


end  HARMONIC.BLOCK.BUILDER; 


with  FILES; 

package  OPERATOR.SCIIEDULER  is 
procedure  TEST  DATA 

procedure  SCHEDULE  INITIAL  SET  (  PRECEDENCE  LIST  : 

SCHEDULE. INPUTS  : 
CONTINUE 

THE  MET  : 

procedure  SCHEDULE.REST.OF.BLOCK  (  SCHEDULE  INPUTS 

THE.NET  ; 

procedure  CREATE.STATIC.SCHEDULE  (SCHEDULE  INPUTS 

STATIC  SCHEDULE 


TEXT  10. IN  FILE; 
TEXT. 10.  0UT.F1LE; 
in  out  BOOLEAN; 
in  out  OPERATORS  ); 
:  TEXT_IO.OUT.FILE; 
in  out  OPERATORS  ); 
TEXT.IO.  IN.FILE; 
TEXT.IO.  OUT.FILE) ; 


FAILJIALF.PERIOD 
BAD.TOTAL  TIME 
RATIO  TOO.BIG 
OVER.TIME 
INVALID.SCHEDULE 
SCHEDULE  ERROR 


exception; 

exception; 

exception; 

exception; 

exception; 

exception; 


end  OPERATOR.SCHEDULER; 


with  TEXT.IO; 

with  FILES; 

with  PSDL.READER; 

with  FILE.PROCESSOR; 

with  TOPOLOGICAL.SORTER; 

with  IIAF.MONI.C_B LOCK.BI.UI LDER; 

with  OPERATOR.SCHEDULER; 

procedure  STATIC.SCHEDULER  is 

task  LNITIATE.STATIC.SCHEDULER; 

begin 
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cask  body  INI T I ATE_STAT IC_S  CHEDULER  is 
begin 

accept  STATIC; 

end  INITIATE_STATIC_SCHED(JL£R; 

PSDL_READER.  INVOKE_AG_PROCESSOR; 

PSDL  READER. READ_THE_FILE; 

FILE  PROCESSOR.  SEPARATE_DATA; 

FILE_PR0CESS0R.  VALIDATE_DATA; 

TOPO LOGIC AL_SORTER.  CREATE_LISTS; 

TOPOLOGICAL_SORTER.  SORT_REMAINING_OPERATORS; 
while  not  END_OF  FILE  loop 

HARMONIC_BLOCK_BUILDER.  CALC_FERIQDIC_EQUIVALENTS: 
end  loop; 

HARMONIC_BLOCK_BUILDER.  S0RTJ3Y  PERIOD; 

HARMONIC_BLOCK_BUILDER.  FIND_BASE_BLOCKS; 

HARMONIC  BLOCK_BUILDER.  FIND_BLOCK  LENGTH; 

OPERATOR_SCHEDULER.  TEST  DATA; 

OPERATOR  SCHEDULER.  SCHEDtJLE_ INITIAL  SET; 

0 P £ E AT 0 R_3 CHEDULER .  SCHEDULE  RESTjJF  BLOCK; 

OPERATOR_SCHEDULER.  CREATE_STATIC_SCHEDULE; 

exception 

when  FILE.PROCESSOR.  MET_NOT_LESS_TIIAN_MRT  => 

PUT_LINE  (  "Cannot  allow  MET  larger  than  or  equal  to  MRT. "  ); 
exception 

when  FILE_PROCESSOR.  MET_EQUALS_PERIOD  => 

PUT_LINE  (  "Caiuiot  allow  MET  equal  to  period."  ); 
exception 

when  TOPOLOGICAL_SORTER.  NO_INITIAL_LINK_OP  => 

PUT_LINE  (  "Cannot  locate  the  initial  link  statement."  ); 
exception 

when  TOPOLOGICAL_SORTER.  NO_MATCHES_FOUND  => 

PUT_LINE  (  "Cannot  locate  any  link  statements  after  the  first, 
exception 

when  HARMONIC_BLOCK_BUILDER.  CONSTRAINTS_INVALID  => 

PUT_LINE  (  "Cannot  build  schedule  with  given  constraints."  ); 
exception 

when  HARMONIC_BLOCK_BUILDER. NO_BASE_BLOCK  => 

PUT_LINE  (  "Cannot  schedule  incompatible  operators. "  ); 
exception 

when  OPERATOR_SCHEDULER. FAIL_HALF_PERIOD  => 

PUT_L1NE  (  "Cannot  guarantee  schedule  will  be  feasible."  ); 
exception 

when  OPERATOR_SCHEDULER.  BAD_TOTAL_TIME  => 

PUT_LINE  (  "Cannot  guarantee  schedule  will  be  feasible."  ); 
exception 

when  OPERATOR_SCiIEDULER.  RATIO_TOO_B  LG  => 

PUT_L1NE  (  "Cannot  guarantee  schedule  will  be  feasible."  ); 
exception 

when  OPERATOR_SCHEDULER.  OVER_TIME  => 

PUT_LINE  (  "Cannot  create  schedule  with  parameters  given."  ); 
exception 

when  OPERATOR_SC!IEDULER.  INVALID_SC11EDULE  => 

PUT_LINE  (  "Cannot  create  schedule  with  parameters  given."  ); 
exception 


m 
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when  OPERATOR.SCIIEDULER.  SCHEIIU1.E.EER0R  => 

PUT.LINE  (  "Cannot  create  schedule  with  parameters  given."  ); 

end  STATIC_SCH£DULER; 


with  TEXT_IO; 

package  body  PSDL.READER  is 
A_W0RD  :  STRING; 

procedure  INVOKE.AG  PROCESSOR  (  PSDL.PROG  :  TEXT.IO.  IN  FILE; 

AG_OUTF I LE  :  TEXT.IO.  OUT.F I LE  ); 

begin 

Run  the  compiled  AG  program 

using  the  PSDI._PROG  as  its  input 

to  create  the  AG_OUTFILE  as  its  output 

end  INV0KE_AG_PR0CESS0R; 


procedure  READ_THE_FILE  (  AG_OUTFILE  :  TEXT_IO. IM_FILE; 

TRASH.FILE  :  TEXT_IO. OUT_FILE; 

begin 

OPEN  (  AG_OUTFILE ,  TEXT  10.  IN.FILE  ); 

CREATE  (  TRASH  FILE,  TEXT.IO.  OUT.FILE  ); 
while  not  TEXT  10.  END_OF_FILE  loop 
GET  (  A_W0RD[i]  :  out  AG_OUTFILE  ); 
if  A_W0RD[i]  =  "JUNK  "  then 
begin 

PUT  (  A_W0RD[i]  :  in  TRASH.FILE  ); 

PUT  (  A_W0RD[i+l]  :  in  TRASH_FIL£  ); 
end; 
end  if; 

A_W0RD[i]  :=  A_W0RD[i+l]; 
end  loop; 

end  READ.THE.FILE; 
end  PSDL_READER; 


with  TEXT.IO; 

package  body  FILE.PKOCESSOR  is 


procedure  SEPARATE.DATA  (  AG.OUTFILE  :  TEXT.IO.  IN.FILF.; 


LINKS 
OPERATORS 
NON  GRITS 


NEW.WORD  :  STRING; 
THE.STATE  :  STRING; 


TEXT  10. OUT.FILE; 
TEXT.IO.  OUT.FILE; 
lEXT  10. OUT.FILE  )  is 
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begin 

OPEN'  ( AG_OUTF I L£  ,  TEXT_TO.  IN_FILE  ); 

CREATE  (  LINKS,  TEXT_IO.  OUT_FILE  1; 

CREATE  (  OPERATORS,  TEXT_I0.  OL’T_FILE  ): 

while  not  TEXT  10. END_0F_FIL£  loop 
GET  (  NEW_W0RD[i]  :  out  AG_0UTFILE  ); 
if  NEW_W0RD[ i]  =  "ID  "  then 

PUT  (  NEW_W0RD[i+l]  :  in  OPERATORS.  TIIE_0PERAT0R_ID  ); 
elsif  NEW_W0RD[i]  =  "STATE  "  then 
THE  STATE  :=  NEW_W0RD[i+l] 
elsif  NEW_W0RD[i]  =  "MET  "  then 

PUT  (  NEW_W0RD[i+n  :  in  OPERATORS.  THE_MET  ); 
elsif  NEW_W0RD[i]  =  MRT  "  then 

PUT  (  NEW  W0RD[i+ll  :  in  OPERATORS.  THE_HRT  ); 
elsif  NEW_W0RD[i]  =  ,fMCP  "  then 

PUT  (  NEW_WORD[i+ll  :  in  OPERATORS.  THE_MCP  ); 
elsif  NEW_W0RD[i]  =  ,fPERI0D  "  then 

PUT  (  NEW_WORD[i+n  :  in  OPERATORS.  THE_PERIOD  ); 
elsif  NEW_W0RD[i  |  =  "WITHIN  "  then 

PUT  (  NEW  V0RD[itll  :  in  OPERATORS.  THE  WITHIN  ); 
elsif  NEW_W0RD[i]  =  ,(LINK  "  then 
begin 

if  NEW_W0P.D[i+3]  =  THE_STATE  and 
NEW_W0RD[i+7]  =  THE_STATE  then 

begin 

--  Discard  this  link  statement  since 
--  it  represents  a  state  machine. 

--  Increment  NEW_W0RD. 

end; 

else 

PUT  (  NEW_WORD[i+l]  :  in  LINKS.  THE_DATA_STREAM  ); 

PUT  (  NEW_W0RD[i+3]  :  in  LINKS.  THE_FIRST_OP_ID  ); 

if  NEW_W0RD[i+4J  :  "  then 

PUT  (  NEW  W0RD[i+5]  :  in  LINKS.  THE_LINK_MET  ); 


PUT  (  NEW_W0RD[i+7]  :  in  LINKS.  THE_SEC0ND_0P_ID  ); 
end  if; 
end  if; 
end; 

else  NEW_W0RD[i]  :=  NEW_W0RD[i+2]; 
end  if; 
end  loop; 

CREATE  (  N0T.CRITS,  TEXT_I0.  OUT_FILE  ); 
while  not  OPERATORS.  ENDjOF_FILE  loop 
if  THE_MET[ i]  =  null  STRING  then 

PUT  (  THE_0PERAT0R_ID[iJ  :  in  N0N_CRITS  ); 
end  if; 

THE_MET[i]  =  THE_MET[i-t-l]; 
end  loop; 

end  SEPARATE_DATA; 
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procedure  VALIDATE_DATA  (  OPERATORS  :  TEXT_IO. IN.FILE  )  is 


begin 

OPEN  (  OPERATORS,  TEXT.IO.  IN.FILE  ); 
while  not  OPERATORS.  END_OF_F I LE  loop 
GET  (  THE.MCPfi]  :  out  OPERATORS  ); 
if  THE_MCP[i]  not=  0  then 
begin 

GET  (  THE_MRT[i]  :  out  OPERATORS  ); 
if  THE_MRT[i]  =  0  then 
begin 

GET  (  THE_VITHIN[.ij  :  out  OPERATORS  ); 
if  THE_WlTHIN[i]  not=  0  then 
THE_MRT[i]  :=  THE_WITHIN[i]; 
end  if; 
end; 
else 

GET  f  THE_?ERIOU[i.l  :  out  OPERATORS  ); 

TKE_MRT[ i]  :=  THE_?ERIOD[ij; 
end  if: 
end; 
end  if; 

--  Two  additional  "if. . . then"  loops  similar  to  the  above  would 
--  also  appear  here  within  the  loop. 

--  (1)  Verify  that  MET  not  =  period, 

else  raise  the  exception  MET_EQUALS_PERIOD. 

--  (2)  Verify  that  MET  <  MRT , 

--  else  raise  the  exception  MET_N0T.LESS_THAN.MRT. 
end  loop; 


end  V AL I D ATE_D AT A ; 
end  FILE_PROCESSOR; 


with  TEXT. 10; 

package  body  TOPOLOGICAL.SORTER  is 


procedure  CREATE.LISTS  (  LINKS  :  TEXT  10. IN.FILE; 

PRECEDENCES  ST  :  TEXT_10.0UT.FILE  )  is 

begin 

CREATE  (  PRECEDENCE  LIST,  TEXT  TO. OUT.FILE  ); 

OPEN  (  LINKS,  TEXT. 10.  IN.FILE  ); 
while  not  LINKS. END_0F.F1 LE  loop 

GET  (  TIIE.FIRST.OP  lD[i]  :  out  LINKS  ); 
loop  THRU_ALL.SECOND.OP  IDS 
GET  (  THE.SEC0ND.0P_! DC j]  :  out  LINKS  ); 
if  THE.F I RST.OP. ID[ j]  never=  THE_SECOND_OP_lD[j]  then 
begin 

PUT  (  TIIE.FIRST.OP. ID  :  in  PRECEUENCE_LIST.THE_LEFT_OP.ID  ); 
PUT  (  THE  SEC0ND.0P.1D  :  in  PRECEDENCE_LIST.T11E_RIGUT_0P.ID;; 


end; 

elsif 

THE_FIRST_OP_ID[ i]  =  any  of  THE_SEnONl)_OP_ID[jJ  then 
exit  this  iteration  and  try  THE_FIRST_OP_ID[i+l]; 
end  loop; 

exception 

when  PRECEDENCE_LI ST  =  null  => 
raise  N0_INITIAL_LINK_0P; 

(exit  and  terminate  the  Static  Scheduler) 

end  CREATE.LISTS; 

procedure  SORT  REMAINING  OPERATORS  (  LINKS  :  TEXT.  10. IN_FILE; 

PRECEDENCE_LI ST  :  TEXT_I0. 0UT_FIL£  )  is 

begin 

GET  (  THE_RIGHT  0P_ID[i]  :  out  PRECEDENCE  LIST  ); 
while  not  PRECEDENCE.LIST. END_0F_FILE  loop 

--  Comparisons  similar  to  procedure  CREATE_LISTS  would 
go  here  but  in  tills  case  vou  want  to  find  instances 
--  where  THE_RIGIIT  0P_ID[i].  PRECEDENCE  LIST  = 
THE_FIRST_OP_ID[i+ij.  LINKS 
if  a  match  is  found  then 

THE  LEFT  0P_ID[i+l]. PRECEDENCE  LIST  := 

THE_FIRST  0P_ID[i+l].  LINKS  and 
THE_R I GHT_0P_ I D[  i+ 1  ] .  PREC£DENCE_LIST  :  = 

THE_SEC0ND_0P_ID[i+l].  LINKS 
end  if; 

THE_RIGHT_OP_ID[i]  :  =  THE_RIGHT_OP_ID[i+l]; 
end  loop; 

exception 

when  PRECEDENCE  LIST  contains  only  an  initial  entry  => 
raise  N0_MATCIIES_F0UND; 

(exit  and  terminate  the  Static  Scheduler) 
end  S  QRT_R£MA INI NG_0PERAT0RS ; 
end  TOPOLOGICAL_SORTER; 


package  body  HARM0NIC_BL0CK_BUILDER  is 


procedure  CALC_PERIODIC_EQUIVALENTS  (  OPERATORS  :  TEXT_I0.  IN_FILE  )  is 
begin 

procedure  L0CATE_SP0RAD1C_0FERAT0R 
begin 

GET  (  THE_MCP[i]  :  out  OPERATORS  ); 
if  found 

GET  (  THE  PERI0D[i]  :  out  OPERATORS  ); 
if  THE_PERI0D[i]  not=  0  then 
begin 
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restart  the.  loop,  this  is  already  a  periodic  operator 
GET  (  THE_MCP[i+lJ  :  out  OPERATORS  ); 
end; 
else 

GET  (  THE_MRT[iJ  :  out  OPERATORS  ); 
if  THE_MRT[ i]  =  0  then 
begin 

THE_MRT[i]  :  =  THE_WITHIN[i]  or  if  no  "within"  in  file 
THE_MRT[ i]  :=  THE_MET[i]; 
end; 
end  if; 
else 

all  operators  are  already  periodic 
exit  this  package 
end  if; 

end  LOCATE_SPORADIC_OPERATOR; 

procedure  VERIFY_1  is 
begin 

GET  (  THE_MCP[i]  :  out  OPERATORS  ); 

GET  (  THE_MRT[i]  :  out  OPERATORS  ); 

exception 

when  THE  MCP[i]  >=  THE_MRT[ i]  => 
raise  CONSTRAINTS_INVALID; 

(exit  and  terminate  the  Static  Scheduler) 

--  Two  additional  checks  are  structured  the  same  as  above 
--  (1)  verify  that  THE_MET[i]  <  THE  MRT[ i] 

--  (2)  verify  that  THE_MET[i]  <  THE JlCP[i] 

--  both  (1)  and  (2)  will  raise  exception  CONSTRAINTS_INVALID 

end  VERIFY.l; 

procedure  PERIOD_ALGO  is 

DIFFERENCE  :  STRING; 

NEW_PERIOD  :  STRING; 

begin 

DIFFERENCE  :=  THE_MRT[i]  -  THE  MET[i]; 

if  DIFFERENCE  <  THE_MCF[i]  and  DIFFERENCE  >  THE_MET[i]  then 
NEW_PERIOD(.i]  :=  DIFFERENCE; 
else 

NEW_PERIOD[i]  :=  THE_MCP[i]; 
end  i f ; 

PUT  (  NEW_PERIOD[i]  :  in  OPERATORS.  THE_PERIOD[i]  ); 
end  PERIOD_ALGO; 
end  C ALC_PER I OD I C_EQUI VALENTS ; 


procedure  SORT_BY_PERIOD  (  THE_PERIOD  :  in  out  OPERATORS  ); 


begin 

perform_sort  in  ascending  order  based  on  THE_PERIOD  in  OPERATORS 
end  SORT_BY_PERIOD; 


procedure  FIND_BASE_B LOCKS  (  THE_PERTOD  :  in  ouc  OPERATORS; 

BASE_BLOCK  :  ouc  INTEGER  )  is 


DIVISOR 
REMAINDER 
ORIG  SEQUENCE 
TEMP_SEQUENC£ 
BASE  BLOCK 


INTEGER; 

INTEGER; 

»; 


{}; 


--  null  sequence 
--  null  sequence 
--  null  sequence 


function  MOD JD I VIDE  (  THE_PERIOD 


begin 

loop  CREATE  PERIOD  SEQUENCE 
GET  (  THE_PERIODUJ  :  out  OPERATORS  ); 

PUT  (  THE  PERIODfi]  :  in  OR£G_SEQUENCE  ); 
end  loop  CREATE  PERIOD  SEQUENCE; 
loop  CREATE  BLOCKS 

GET  (  THE_PERIOD[i]  :  out  ORIG_SEQUENCE  ); 
DIVISOR  :  =  THE_PERIOD[i]; 
loop  INNER 


out  ORIG_SEQUENCE  )  returns 

REMAINDER; 


function  MOD_DIVIDE  returns  REMAINDER  is 
REMAINDER  :=  THE_PERIOD[iJ  /  DIVISOR; 
return  REMAINDER; 
end  MOD_DIVIDE; 


in  BASE_BLOCK  ); 
in  TEMP_SEQUENCE  ); 


if  REMAINDER  =  0  then 
PUT  (  TIIE_PERIOD[iJ 
else 

PUT  (  THE_PERIOD[i] 
end  if; 

end  loop  INNER  when  the  0R1Q_SEQUENCE  —  {}; 
if  TEMP_SEQUENCE  =  {}  then  return 

--  loop  CREATE_PERIOD_SEQUENCE  is  completed 
elsif 

TEMP_SEQUENCE  not=  {}  and  DIVISOR  not=  1  then 
begin 

ORIG_SEQUENCE  :=  BASE_BLOCK  U  TEMP_SEQUENCE; 
end; 

else 


--  null 


exception 

when  TEMP_SEQUENCE  not=  {}  and  DIVISOR  =  1  => 
raise  NO__BASE_BLOCK; 

(exit  and  terminate  the  Static  Scheduler) 


end  loop  CREATE_BLUCKS; 
end  FIND_BASE_BLOCKS; 
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<  ^  w  yv  vlfx*  ktv.»  x7v  ^rA,.v-rJ,vA".vA’w^L'v^-.’y',  ,>  -t  V’_fc  ->  ->  -_v  r>: 


procedure  FIND_BLOCK_L£NGTH  (  BASE  BLOCK  :  in  out  INTEGER; 

HARMON  I  C_B  L0CK_LENGT1I  :  out  INTEGER  )  is 


NEW_GCD 
NEW  LCM 
LCM 
GCD 
ENTRY 


INTEGER 

INTEGER 

INTEGER 

INTEGER 

INTEGER 


function  FIND  GCD  (  ENTRY  :  in  BASE  BLOCK  )  returns  NEW  GCD; 
function  FIND_LCM  (  ENTRY  :  in  BASE_BLQCK  )  returns  NEW_LCM; 

begin 

GET  (  ENTRY[i]  :  out  BASE  BLOCK  ); 

GCD  :=  ENTRYfi]; 

LCM  :=  ENTRY[i]; 

GET  (  ENTRY! i+1]  :  out  3ASE.BL0CK  ); 
while  3ASE_3LOCK  not=  ij  loop 

function  FIND..GCD  returns  NEW_GCD  is 
begin 

while  GCD  not  =  0  loop 
REMAINS  1  :=  LCM  mod  GCD; 

REMAINS 2  :=  ENTRY[i+l]  mod  GCD; 
if  REMAINS  1  =  0  and  REMA1NS2  =  0  then 
begin 

NEW_GCD  :  =  GCD; 
return  NEW_GCD; 
end; 
else 

GCD  :=  GCD  >  1; 
end  if; 
end  loop; 
end  FIND_GCD; 

function  FIND_LCM  returns  NEW_GCD  is 
begin 

NEW_LCM  :=  (  LCM  *  ENTRY[  i+1]  /  GCD  ); 
return  NEW  LCM; 
end  FIND_LCM; 

ENTRY[  i]  :  =  ENTRY[i+l]; 

GET  (  ENTRY[i]  :  out  BASE  BLOCK  ); 

LCM  :=  NEW_LCM; 

GCD  :=  NEW_GCD; 
end  loop; 

IIARMONIC_BLOCK_LENGTH  :  =  LCM; 
end  F IND_B  LOCK_LENGTH ; 
end  HARMONIC  BLOCK  BUILDER: 


k.  r  w  ** 


with  FILES; 
with  TEXT_IO; 

package  body  OPEKATOR_SCIIEDULER  is 

procedure  TEST_DATA  is 
begin 

procedure  CALC_HALF_PERIODS  (  OPERATORS  :  TEXT_I0.  IN_FILE  )  is 

function  DIVIDE_PERI0D_BY_2  (  THE  PERIOD  :  out  OPERATORS  )  returns 

iIALF_PERIODS; 

begin 

function  DIVIDE  PERIOD  BY_2  returns  HALF_PERIODS  is 
HALF_PERIOD  :  REAL; 
begin 

while  not  OPERATORS. END_0F_F I LE  loop 
begin 

GET  (  THE  PERI0D[i]  :  out  OPERATORS  ); 

GET  (  THE  MET[i]  :  out  OPERATORS  ); 

HALF  PERIOD  :  =  THE  PERIOD[  i]  /  2; 
if  HALF.PERIOD  =<  THEJlET[i]  then 

exception 

raise  FAILJLALF.PERIOD; 

end  if; 
end; 

end  loop; 

end  CALCJIALF.PERIODS; 


procedure  CALC  TOTAL  TIME  (  OPERATORS  :  TEXT  10. IN.FILE; 

HARMON I C_B LOC K.LENGTH  :  in  INTEGER  )  is 


TIMES  : 

REAL 

:=  0.  0; 

OP  TIME  : 

REAL 

:=  0.  0; 

TOTAL  TIME: 

REAL 

:=  0.  0; 

function  CALC_N0_0F_PERI0DS  (  IIARMONIC_BLOCK_ LENGTH  :  out  OPERATORS; 

THE_PERIOD  :  out  OPERATORS  )  returns  TIMES; 
function  MULTIPLY_BY_NET  (  TIMES  :  in  out  REAL; 

TI!E_MET  :  out  OPERATORS  )  returns  0P_TIME; 
function  ADD_T0_SUM  (  0P_TIME  :  in  out  REAL  )  returns  TOTAL_TIME; 

begin 

while  not  OPERATORS.  END_0F_F I LE  loop 
begin 

function  CALC_N0_0F_PERI0DS  returns  TIMES  is 
begin 

GET  (  THE_PERl0D[iJ  :  in  out  OPERATORS  ); 

TIMES  :=  1 1 ARMON I C_B LCCK_LENGTH  /  TIiE_PERIOD[i]; 
return  TIMES; 
end  C ALC_N0_0F_PE R I ODS ; 


I1' 
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I 
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function  MlTLTIFLY_BY_MET  returns  OP_TIME  is 
begin 

GET  (  THE_MET[ j]  :  in  out  OPERATORS  ); 
OP_TIME  :=  TIMES  *  TiIE_MET[i]; 
return  OP_TIME; 
end  MULTI PLY_BY_MET ; 

function  ADD_TO_SUM  returns  TOTAL_TItlE  is 
begin 

TOTAL_TIME  :=  TOTAL_TIME  +  OP  TIME; 
return  TOTAL  TIME; 
end  ADD_TO_SUM; 

end; 

end  loop; 
exception 

when  TOTAL_TIME  >  HARMONIC  BLOCK_ LENGTH  => 
raise  BAD_TOTAL_TIM£; 

(exit  and  terminate  the  Static  Schedule) 
end  CALC_TOTAL_TIME; 


procedure  CALC_RATIO_SUM  (  OPERATORS  :  TEXT_I0.  IN_FILE  )  is 

RATIO  :  REAL  : =  0. 0; 

RATI0_SUM  :  REAL  :=  0.0; 

function  DIVIDE_MET_BY  PERIOD  (  T!IE_MET  :  in  out  OPERATORS; 

THE.PERIOD  :  in  out  OPERATORS  )  returns  RATIO; 
function  ADD_TO_TIME  (  RATIO  :  in  out  REAL  )  returns  RATIO.SUM; 

begin 

while  not  OPERATORS.  END_0F_F I L£  loop 
begin 

function  D I VI DE_MET_B Y_PER I OD  returns  RATIO  is 
begin 

GET  (  THE_MET[i]  :  out  OPERATORS  ); 

GET  (  THE  PERI0D[i]  :  out  OPERATORS  ); 

RATIO  :=  THE.MET  /  TilE_PERIOD; 
return  RATIO; 
end  DIVIDE_MET_BY_PERIOD; 

function  ADD_T0_T.IM£  returns  RATI0_SUM  is 
begin 

RATI0_SUM  :=  RAIT0_SUM  +  RATIO; 
return  RATI0_SUM; 
end  ADD_TO_SUM; 

end; 

end  loop; 


exception 


when  RATIO_SUM  >  0. 5  => 
raise  RATIO_TCO_BIG; 

(exit  and  terminate  the  Static  Scheduler) 
end  C ALC_RAT I 0_SUH ; 
end  TEST_DATA; 


procedure  VERIFY_TIME_LEFT  (  HARMON IC_BLOCK_LENGTH  :  in  INTEGER; 

TIME  :  in  INTEGER; 

CONTINUE  :  BOOLEAN  ); 

begin 

if  TIME  >=  HARMON I C_B LOCK  LENGTH  then 
CONTINUE  :=  FALSE; 
else 

exception 

raise  OVER_TIME; 

(.exit  and  terminate  the  Static  Scheduler) 
end  VERIFY_TIME_LEFT; 


procedure  CREATE_INTERVAL  (  THE  PERIODS  :  in  OPERATORS; 

SCH£DULE_INPUTS  :  TEXT_I0. 0UT_FILE  )  is 

LOWER.BOUND  :  INTEGER  :=  0; 

UPPER.BOUND  :  INTEGER  :=  0; 

function  CALC.LOWER  (  TIME  :  in  out  INTEGER; 

THE_PERIOD  :  in  out  OPERATORS  )  returns  LOWER_BOUND; 
function  CALCJJPPER  (  TIME  :  in  out  INTEGER; 

THE.PERIOD  :  in  out  OPERATORS; 

THE_MET  :  in  out  OPERATORS  )  returns  UPFER_BOUND; 

begin 

function  CALC_LOWER  returns  LOWER_BOUND  is 
begin 

GET  (  THE_START[i]  :  in  out  SC!!EDULE_INFUTS  ); 

GET  (  THE  PERI0D[i]  :  in  out  OPERATORS  ); 

LOWER_BOUND[i]  :=  THE  START[.i]  +  THE  PERI0D[i]; 
returns  LOWER_BOUND; 
end  CALC_L0WER; 

PUT  (  L0WER_B0UND[ ij  :  out  SCI1EDULE_INPUTS.  TIlE_LOWER[i]  ); 

function  CALC_UPPER  returns  UPPER_BOUND  is 
begin 

GET  (  THE_START[  i]  :  in  out  PRECEDENCE_LIST  ); 

GET  (  TIlE_PERIOD[i]  :  in  out  OPERATORS  ); 

GET  (  THE_MET[i]  :  in  out  OPERATORS  ); 

UPPER_BOUND[i]  :=  [THE_START[ i]  +  ( 2*THE  PERI0D[i])  -  TIIE_MET[i]  ]; 
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returns  Uri'ER_BOUN’D; 

“rid  CALC_UPPER; 

PUT  (  UPPER_BOUND[i]  :  out  SCHEDULE_INPUTS.  THE_UPPER[i]  ); 
end  CREATE_INTERVAL; 


procedure  SCHEDULE  INITIAL_SET  (  PRECEDF.NCE_T,IST  :  TEXT_IO.  IN  FILE: 

SCHEDU LE_ INPUTS  :  TEXT  10. OUT  FILE; 
CONTINUE  :  in  out  BOOLEAN; 

THE_MET  :  in  out  OPERATORS  )  is 

START  TIME  :  INTEGER  :=  0; 

STOPjflME  :  INTEGER  :=  0; 

begin 

procedure  VER IFY_TI ME_LEFT  C  CONTINUE  :  in  out  BOOLEAN  ); 
begin 

while  not  PRECEDENCE_LIST. END_OF_FILE  loop 

GET  (THE_LEFT_OP  ID[i]  :  in  out  PREC£DENCE_LIST  ); 
if  THE_LEFT_OP_ ID  not=  EXTERNAL  then 
begin 

PUT  (  THE_LEFT_OP_ID  :  in  SCHEDULE_INPUTS.  OPERATOR[.i J  ); 
PUT  (  START  TIME  :  in  SCHEDULE  INPUTS. THE  START[i]  1; 

GET  (  THE_MET[i]  :  in  out  OPERATOR  ); 

STOP_TIME[i]  :  =  START_TIME[i]  +  THE_MET[i]; 

PUT  (  THE  STOP.TIMEfi]  :  in  SCHEDULE.INPUTS.  THE_ST0P[i]  ); 
end; 

6  Is  6 

restart  with  THE_LEFT_OP_ID[i+l]; 
end  if; 

START.TIME  :=  STOP_TIME[i]; 
procedure  CREATE_INTERVAL; 
end  loop; 
end; 

end  SCHEDUL£_INITIAL_SET; 


procedure  SCHEDULE_REST_OF_BLOCK  (SCHF.DUI.E  INPUTS  :  TEXT  10. 0UT_FILE; 

CONTINUE  :  in  out  BOOLEAN; 

TI1£_MET  :  in  out  OPERATORS  )  is 

begin 

procedure  VERIFY_TIME_LEFT  (  CONTINUE  :  in  out  BOOLEAN  ); 
while  not  SCHEDULE^ INPUTS.  END_OF_I’ILE  loop 

GET  (  THE_L0V,’ER.  '  SMALLEST  :  in  out  SC1IEDULE_1NTUT3  ); 

GET  (  THE_ST0P.  'LARGEST  :  :  n  out  SC11EUULE_INPUT3  ); 
if  THE.LOWER. 'SMALLEST  >=  THE_ST0P. 'LARGEST  then 
begin 

STARTJI'TME  :=  T(IE_L0WER.  'SMALLEST; 

GET  (OPERATOR. 'SMALLEST  :  in  out  SCHEDULE.INPUTS  ); 

PUT  (  START  TIME  in  SCHEDULE_INPUTS. THE_START  ); 

GET  (  THE_MET  :  in  out  OPERATORS  ); 


STOPJTJME  :  =  START_TIMF.  (-  THE_MET ; 

PUT  (  STOP_TIME  :  in  SCU£DUL£_1NFUTS.  TIIE_STOP  ); 
end; 
else 


exception 

when  others  => 

raise  INVALID_SCHEDULE; 

(exic  and  terminate  the  Static  Scheduler) 
end  if; 

START_TIME  : =  ST0P_TIME; 
procedure  CREATE_INTERVAL; 
end  loop; 

end  SCHEDULE_REST_QF_3L0CK; 

procedure  CR£ATE_STATIG_SGHEDULE  (  SCHEDULE_INPUTS  :  TEXT_IO. IN.FILE; 

STATIC_SCHEDULE  :  TEXT_I0. OUT.FILE  )  is 


begin 

CREATE  (  STATIC_SCHEDULE  :  TEXT_IO.  OUT  FILE  ); 

PUT_LINE  ("package  THE_STATIG_SCHEDULE  is  "); 

PUT_LINE  ("task  SEQUENCE  0F_CALLS  is  "); 
while  not  SCHEDULE_INPUTS.  END_OF_FILE  loop 
begin 

GET  (  OPERATOR[i]  :  in  out  SCHEDULE_INPUTS  ); 

PUT  ("entry  EACH_OPERATOR. "  OPERATORfi]  ); 

GET  (  TI1E_START[  i]  :  in  out  SCHEDULE_INPUTS  ): 

PUT  LINE  (  "( "THE_START[i]"  :  in  out  INTEGER;"  ); 

GET  (  THE_STOP[i]  :  in  out  SCHEDULE  INPUTS  ); 

PUT_LINF.  (  THE_ST0P[i]"  :  in  out  INTEGER);"  ); 

GET  (  THE  START[i+l]  :  in  out  SCHEDULE_INPUTS  ); 
if  THE_START[i+l]  =  THE_ST0P[i]  then 
begin 

OPERATOR[iJ  :=  OPERATOR[i+l]; 
return  to  the  beginning  of  the  loop 
end; 
elsif 

THE_START[ i+ 1]  >  THE_STOP[i]  then 
begin 

PUT_LINE  ("entry  DYNAMIC  ("THE  STOP[i]"  :  in  out  INTEGER;"  ); 
PUT_LINE  ( THE_START[ i+ 1]  "  :  in  out  INTEGER  );"  ); 

OPERATOR[i]  :=  OPERATOR[i+l]; 
return  to  beginning  of  the  loop; 
end; 
else 


exception 

when  THE_START[ i+ 1 1  <  THE_STOP[iJ  => 
raise  SCHEDULE_ERROR; 

(exit  and  terminate  the  Static  Scheduler) 

end  if; 
end; 

end  loop; 
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PUT_LINE  (  "end  SEQUENCE_OF_CALLS; "  ); 


whi  le 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
PUT 
FUT 
PUT 
PUT 
PUT 
PUT 
PUT 


not  SCHEDULE_ INPUTS .  END_OF_F I LE  loop 
LINE  (  "with  CALENDAR;"  ); 

LINE  (  "package  body  THE_STATIC_SCHEDULE  is" 

LINE  (  "begin"  ); 

LINE  (  "task  body  S£QUENCE_GF_CALLS  is"  ); 

LINE  (  "begin"  ); 

LINE  (  "loop"  ); 

LINE  (  "procedure  THE_0PERAT0R  is"  ); 

LINE  (  "begin"  ); 

("accept  £ACH_OPERATOR. "  OPERATOR[i]  ); 

LINE  (  "  ("  THE_START[i]"  :  in  out  INTEGER;"  ); 

LINE  (  THE_STOP[i]  "  :  in  out  INTEGER  )  do"  ); 

LINE  (  "select"  ); 

LINE  (  "when  CLOCK.  VALUE  <  "  TH£_ST0P[i]  "  then" 
LINE  (  "entry  DYNAMIC"  ); 

_LINE  (  "or"  ); 

'_LINE  (  "when  CLOCK.  VALUE  =  "  T!TF._STOIT i]  "  then"  ); 


second  time  for  body 

); 


); 


LINE 

LINE 

LINE 

LINE 

LINE 

LINE 

LINE 

LINE 

LINE 


(  "entrv  EACH  OPERATOR."  GFERATOR(i*l]  ); 
(  "else"  ); 

(  "exception"  ); 

(  "when  others  =>"  ); 

(  "raise  RUNTIME.MET  FAILURE"  ); 

(  "end  THE_OPERATOR; "  ); 

(  "end  loop;"  ); 

(  "end  SEQUENCE_OF_CALLS; "  ); 

(  "end  THE_STATIC_SCHEDULE; "  ); 


end  OPERATOR_SCHEDULER; 


end  STATIC_SCHEDULER; 
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APPENDIX  F.  LIST  OF  ACRONYMS 


AG 

Attribute  Giammar 

CAPS 

Computer  Aided  Prototyping  System 

CLE 

Combiner  Linker  Exporter 

DFD 

Data  Flow  Diagram 

DOD 

Department  of  Defense 

DON 

Department  of  the  Navy 

ESS 

Execution  Support  System 

FIFO 

First-In  First-Out 

GCD 

Greatest  Common  Denominator 

1,0 

Input  Output 

LCM 

Least  Common  Multiple 

MCP 

Minimum  Calling  Period 

MET 

Maximum  Execution  l  ime 

MRT 

Maximum  Response  Time 

PSDL 

Prototype  System  Description  Language 

.SDMS 

Software  Design  Management  System 

SECNAV 

Secretary  of  the  Navy' 

SS.TDMA 

Satellite-Switched  Time  Division 

Multiple  Access 

TDM  A 

Time  Division  Multiple  Access 

LT 

User  Interface 

d 


a 


a 
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